j

    jimn

    2 years ago
    is
    "string".size
    unreasonable as a stdlib feature?
    Thomas

    Thomas

    2 years ago
    Do you mean
    "string".length
    ?
    j

    jimn

    2 years ago
    i meant it as asked. the java 1.0 team was an R&D operation building a scatterbrained set-top box bytecode interpretter, not a psuedofunctional DSEL enabled language set 30 years into the future
    String.length and Array.size and List.size() are all casualties of the browser race
    karelpeeters

    karelpeeters

    2 years ago
    What?
    j

    jimn

    2 years ago
    @karelpeeters is
    "string".size
    unreasonable as a stdlib feature?
    karelpeeters

    karelpeeters

    2 years ago
    Yes, it's just adding a third way to get the same thing as
    length
    and
    count()
    . But my "what" was more a reaction to your two other comments, what are you talking about?
    j

    jimn

    2 years ago
    so, James Gosling's absent minded choice to use size in one place and length in another is a good thing because it's what came first?
    and array.size, string.size, list.size, all these things should be specialized cases of syntax choices made by java 1.0 ?
    the point i made about the browser race, if you were too young to be professionally employed solving software programs in the early 90's, was the dotcom fueled race to heap branded piles of shit on top of html to control the future of the web, of which java and javascript are two examples
    java was being designed for a menu system on a set-top box. the interesting feature was bytecode, not the choice of language features.
    karelpeeters

    karelpeeters

    2 years ago
    And you're blaming some peculiar naming choice on all of this?
    James Gosling's absent minded choice to use size in one place and length in another is a good thing because it's what came first?
    Yes, sometimes it's better to just keep what's already there instead of constantly making trivial changes for tiny cosmetic improvements.
    j

    jimn

    2 years ago
    no, my question was pretty simple.
    m

    Mike

    2 years ago
    I agree with Jim that it would be nice if all these 'collections' had the same ways of getting their 'length/size'. And I wish it was just one way. Alternatively, it should support all 3. length, size and count.
    So @jimn I don't think it's unreasonable, so I'd suggest it. The JB team can decide to reject or adopt it.
    karelpeeters

    karelpeeters

    2 years ago
    I agree it would be nice, but I don't thunk it's work adding yet another option, then we'll just get confused and start using
    length
    and
    size
    interchangeably within the same codebase.
    j

    jimn

    2 years ago
    Yes, sometimes it's better to just keep what's already there instead of constantly making trivial changes for tiny cosmetic improvements. (edited)
    i forgot we're in #java on efnet and not the kotlin slack
    there are a lot of type system gaps in abstraction that could have been more elegant, but 30 year old java naming anacronisms have no merit
    i dont mind the synonynms, given the history, it makes sense to keep the old names as aliases. i don't think you can have a more noticable abberation of the collections hierarchy than renaming the .size member 3 ways.
    s

    serebit

    2 years ago
    You seem awfully antagonistic about this
    You asked for others' opinions directly, there's no need to verbally assault people who disagree with you
    Dmitry Kandalov

    Dmitry Kandalov

    2 years ago
    +100 for deprecating
    String.length
    and making it
    .size
    .
    d

    diesieben07

    2 years ago
    length
    implies indices for me (an array has length).
    size
    doesn't (for e.g. Sets).
    j

    jimn

    2 years ago
    @serebit "constantly making trivial changes for tiny cosmetic improvements" is a sort of condescending response among a series of same from this particular individual towards my threads. So you're probably right about being short with these responses. trivialisation of the intent of the question.
    #stdlib sort of implies language lawyer focus on whether a thing is good for the stdlib overall, and pros and cons discussions. being dismissive of a question because of tradition or comfort or familiarity is relevant when discussing removal of features for which those sentiments apply and may add technical debt. the opposite of that - using tradition or comfort or familiarity to shoot down an additive refactoring should probably be called FUD when the rationale is not as plainly objective as can be stated. Is it reasonable to remove .length? "I think that would add technical debt" is pretty objective. Is it reasonable to add .size? "Even though we can increase polymorphism in unplanned emergent properties of the libraries and languages that followed, we will add 64bytes to each class file that currently lacks that alias"
    Dmitry Kandalov

    Dmitry Kandalov

    2 years ago
    IMHO kotlin to large extent has been a lot of "small" improvements over java which overall make a big difference so no improvement is too trivial. Plus there was an intention to keep the language evolving by using migrations, etc. and not trying to be forever backward compatible like java so switching from
    .length
    to
    .size
    could probably be done within two major versions with no additional runtime cost.
    Another reason to prefer "size" is that it's shorter (i.e. less typing) and takes more effort to misspell unlike "lenght" 🙂