Elliotte Rusty Harold's take on Java

[Justin Johansson]

Do you guys think it might be an idea to fork the thread?

Subject say "Syntactic sugar and OOP"

JJ


Lutger Wrote:

> Yigal Chripun wrote:
> 
> > On 17/09/2009 16:15, Justin Johansson wrote:
> >>> making primitives full objects is the right design and has nothing to do
> >>> with bloat which just means the implementation sucks.
> >>>
> >>> consider:
> >>>
> >>> struct Integer(int bits, signed = true) {...}
> >>> with specializations for 8, 16, 32, 64
> >>>
> >>> Integer!(32) will have the same size as an int since structs don't have
> >>> vtables in D.
> >>>
> >>> of course, for this to be truly useful the compiler needs to understand
> >>> "123.methodName()" kind of code.
> >>
> >> And I'm guessing you didn't mean auto-boxing either?
> >>
> > 
> > of course not. auto boxing is a patch for a broken design.
> > 
> > it's already possible to define in D:
> > void func(type[] arr, params) {}
> > and use it as:
> > type[] arr;
> > arr.func(params);
> > 
> > applied to strings (which are just regular arrays in D), you can do:
> > 
> > string str = "Hello World";
> > str.toUpper(); // assume to upper is defined as above.
> > 
> > next step would be to allow the same for literals:
> > "hello World".toUpper();
> > 
>> now let's take the above one step further. why limit this to arrays? why
>> not make it work for numbers as well?
>> 123.next(); could be understood by the compiler as
>> Integer.next(123);
>> 
>> No bloat required.
> 
> This is already supposed to be in D under the name of extension methods. But 
> it is just another syntax for a function call, what has this to do with OOP?
>