is `"string".size` unreasonable as a stdlib featu...

# stdlib

[jimn]

is "string".size unreasonable as a stdlib feature?

[Thomas]

Do you mean "string".length?

[jimn]

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

[jimn]

String.length and Array.size and List.size() are all casualties of the browser race

[karelpeeters]

What?

[jimn]

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

[karelpeeters]

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?

[jimn]

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?

[jimn]

and array.size, string.size, list.size, all these things should be specialized cases of syntax choices made by java 1.0 ?

[jimn]

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

[jimn]

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]

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.

[jimn]

no, my question was pretty simple.

[Mike]

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.

[Mike]

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]

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.

[jimn]

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

[jimn]

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

[jimn]

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.

[serebit]

You seem awfully antagonistic about this

[serebit]

You asked for others' opinions directly, there's no need to verbally assault people who disagree with you

[Dmitry Kandalov]

+100 for deprecating String.length and making it .size.

[diesieben07]

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

[jimn]

@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.

[jimn]

#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]

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.

[Dmitry Kandalov]

Another reason to prefer "size" is that it's shorter (i.e. less typing) and takes more effort to misspell unlike "lenght" 🙂