about having something similar to the extend attribute ?
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 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).
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
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/9/07, Peter Hall <peterjoel at gmail.com> 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
as seen here 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 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;
}
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
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