about having something similar to the extend attribute ?

Peter Hall peterjoel at gmail.com
Tue Jan 9 02:06:12 PST 2007


Personally, I think that inheritance can be confusing enough by
itself, in terms of making it hard to know where in the chain a method
is defined. Allowing methods to be appended in namespaces would surely
make that even more confusing? At least with static utils, it's
transparent.

Your use-cases don't really demonstrate any benefits that couldn't be
achieved another way, except an aesthetic one - which is a matter of
personal taste anyway..

Like you, I'd shy away from prototype hacking. I'd want my code to be
compatible with strict mode, even if that wasn't a current
requirement. But - for me - aggregation, inheritence and static utils
seem to have all the bases covered.

Peter


On 1/8/07, zwetan <zwetan at gmail.com> wrote:
> On 1/8/07, Peter Hall <peterjoel at gmail.com> wrote:
> > Do you see any practical advantage of this over just using static or
> > package-level methods and passing an instance as an argument?
> >
>
> yes, all these advantages:
>
> - being able to augment buildins classes with new behaviours
>   basic example of scramble/unscramble
>   most of people will not care to have those methods for general use
>   but someone doing a lot of programming with games having to scramble
>   text will be happy to have this features directly in the String class
>
> - less typing, better naming convention
>   example:
>   I love the String.Format() method in C#
>   it s well named, make perfect send to have it defined in the String class
>   and it's more than usefull for formatting text
>   I want to have the same method in ES4 because I can not live without it
>   what are the options now ?
>
>   -> defining a static in a StingUtil lib
>       sorry but String.format() is a better naming scheme imho
>   -> compiling in standard mode and adding the method to the String class object
>       we loose all the good things of strict mode (the speed of Tamarin VM :))
>   -> harassing TG1 till they include it by default in ES4 (unlikely to succeed)
>
>   I think that till you don't want to override something already defined
>   you should be allowed to add to it
>   adding String.format -> good, harm no one
>   changing String.replace -> bad, people will expect the standard behaviour
>
>   It follow the same logic, from ES3 to ES4
>   Array got new methods
>   String got new methods
>   etc..
>   people were adding it to the prototype because they were usefull
>
>   ES4 committee will never have the time to define and implement
>   a ES4 framework (meaning going beyond the buildin classes)
>   as what we have in Java or .NET
>   and mind me that's not necessary to have
>   but still if some people want to implement such things
>   a kind of extend attribute will be more than welcome I think
>
>
> - clean API easyly extensible
>
>   use case:
>   you distribute a library as bytecode (abc)
>   people can still extend it even without the source code
>
>   the library is extensible but you can not break it or change its behaviour
>   but you can add behaviours / utilities / addon / etc..
>
>   example:
>   using tons of third party libraries (closed source or not)
>   one could easyly add a toSomething method to all the objects
>   for ex toXML, toJSONString, etc..
>
> - it allows you to add your own namespace to an existing class
>   without touching / modifying the internal of this class
>
>   use case:
>   dynamic programming to its best
>   why agregate, inherit etc.
>   when you just want to patch things up
>   in a certain context or at a certain moment
>
>   example:
>   with the class Number, Int, Uint, Math
>   one could add a Big namespace to those buildin classes
>   and so could compute big integer and big float
>   -> this will not change the way numbers working by default in ES4
>   -> it will allow to have a big number context in special cases
>       but using standard numbers class transparently
>
>
> zwetan
>



More information about the Es4-discuss mailing list