Elliotte Rusty Harold's take on Java

Lutger lutger.blijdestijn at gmail.com
Thu Sep 17 12:36:48 PDT 2009


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?




More information about the Digitalmars-d mailing list