about having something similar to the extend attribute ?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

about having something similar to the extend attribute ?

zwetan-3
as seen here
http://www.mozilla.org/js/language/js20/rationale/miscellaneous.html

Class Extensions / extend Attribute

"namespace StringExtension;

StringExtension extend(String) function scramble():String {...}
StringExtension extend(String) function unscramble():String {...}

use namespace(StringExtension);

var x:String = "abc".scramble();"

would it be as much complicated to use namespace shadowing
http://developer.mozilla.org/es4/proposals/namespace_shadowing.html
to obtain the same kind of behaviour, simply put "add methods to a
class defined somewhere else" ?

for ex:

package
{
        public final class String extends Object
        {
        ...
        }
}

being able to define an extension like this

package
{
        public namespace StringExtension;

        StringExtension class String extends Object
        {
        ...
        public function scramble():String {...}
        public function unscramble():String {...}
        ...
        }
}


and then use it in strict mode

use namespace StringExtension;
var foobar:String = "abcdef".scramble();


for now the only option to do that is to be in standard mode
and add to the prototype, this is good
but as a dev what I really want is the strict mode
but still being able to extend such final class
(even if that idea may raise some hairs in horror ;))

zwetan

Reply | Threaded
Open this post in threaded view
|

Re: about having something similar to the extend attribute ?

Peter Hall-2
Do you see any practical advantage of this over just using static or
package-level methods and passing an instance as an argument?

Peter

On 1/6/07, zwetan <[hidden email]> wrote:

> as seen here
> http://www.mozilla.org/js/language/js20/rationale/miscellaneous.html
>
> Class Extensions / extend Attribute
>
> "namespace StringExtension;
>
> StringExtension extend(String) function scramble():String {...}
> StringExtension extend(String) function unscramble():String {...}
>
> use namespace(StringExtension);
>
> var x:String = "abc".scramble();"
>
> would it be as much complicated to use namespace shadowing
> http://developer.mozilla.org/es4/proposals/namespace_shadowing.html
> to obtain the same kind of behaviour, simply put "add methods to a
> class defined somewhere else" ?
>
> for ex:
>
> package
> {
>         public final class String extends Object
>         {
>         ...
>         }
> }
>
> being able to define an extension like this
>
> package
> {
>         public namespace StringExtension;
>
>         StringExtension class String extends Object
>         {
>         ...
>         public function scramble():String {...}
>         public function unscramble():String {...}
>         ...
>         }
> }
>
>
> and then use it in strict mode
>
> use namespace StringExtension;
> var foobar:String = "abcdef".scramble();
>
>
> for now the only option to do that is to be in standard mode
> and add to the prototype, this is good
> but as a dev what I really want is the strict mode
> but still being able to extend such final class
> (even if that idea may raise some hairs in horror ;))
>
> zwetan
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>

Reply | Threaded
Open this post in threaded view
|

Re: about having something similar to the extend attribute ?

Brendan Eich-2
On Jan 8, 2007, at 11:00 AM, Peter Hall wrote:

> Do you see any practical advantage of this over just using static or
> package-level methods and passing an instance as an argument?

Or another approach: plain old prototype hacking.  True, you can't  
make "fixtures" (AS3's traits, i.e., type-constrained properties that  
cannot be removed or subverted).  Perhaps there ought to be a way to  
do that, since today's JS extends String by simply setting new  
properties of String.prototype (frowned upon among Ajax experts, but  
still done).

/be


Reply | Threaded
Open this post in threaded view
|

Re: about having something similar to the extend attribute ?

zwetan-3
In reply to this post by Peter Hall-2
On 1/8/07, Peter Hall <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: about having something similar to the extend attribute ?

Peter Hall-2
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 <[hidden email]> wrote:

> On 1/8/07, Peter Hall <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: about having something similar to the extend attribute ?

zwetan-3
On 1/9/07, Peter Hall <[hidden email]> wrote:
> 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.
>

It does not change the default behaviour of inheritance,
it's like the namespace shadowing
people not aware of it will at most not notice it
people aware of it will use it for advanced setup

I don't see where could be the confusion ?


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

the benefit of clean and well named API is more than just personnal taste imho


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

I just want the best of both world

well I don't want to shy away from prototype hacking :D
the very one thing that made ES3 stand out for me is the prototype

here how I see it

with ES3, you got only buildins, no frameworks
but as you can hack the prototype, you can add functionnalities to
those buildins
and have a light kind of framework dedicated to your actual task

with ES4, same set up, only buildins (a little more than in ES3), no frameworks
you can still hack the prototype but only in standard mode

if we could have a kind of "extends attribute" with namespace shadowing
it would allow us to hack the class in strict mode
but without breaking them

some other use case:
I define a Char class almost as it was a buildin
I would like to add a toChar method to the String class

later someone else need this Char class to export to XML
because he's using WDDX
he can add the toWDDX() method to the Char class

and on...
and on...


I'm not talking about
"how that would be cool to change the toString method of the Number class"

I'm talking about
"it is more usefull to add a toHexString method to the Number class
directly than any other place"


also look at how frameworks are build in Python
and compare with Java and .NET/C#

in Python you have String extensions and nobody is shocked with that
so why should we in ES4 ?

zwetan