Re: [Prototype-core] Re: For() loops, ++i, i++, i+=1
+1,000,000,000 (cycles) -1 on downplaying really nerdy optimizations :) you curmudgeon you (nice word, btw) --- Warm Regards, Ryan Gahl On Thu, Dec 17, 2009 at 9:33 AM, Bob Kerns r...@acm.org wrote: Not to be a curmudgeon about it -- I'll just point out that the CPU cycles consumed in processing the email for this discussion far exceeds the CPU cycles saved by all the code the lot of you will ever write with such tweaks. Purely entertainment / mental game play. If you want to improve performance, the mental effort would be better spent looking at your algorithm, or even better, measuring the performance to find where you need to focus your attention. I can tell you now it won't be your choice of iteration statements! Play on -- I just wanted to put it into context... -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Function.EMPTY and Function.K
Are you sure not Function.eMpTy ? :P --- Warm Regards, Ryan Gahl On Fri, Oct 16, 2009 at 6:15 AM, Joran Greef jorangr...@gmail.com wrote: Function.IDENTITY and Function.EMPTY are never called directly, though. They're canonical functions. Agreed. Hence, Function.reference instead of Function.empty. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
Extends your Prototype, the Force does, mnn... --- Warm Regards, Ryan Gahl On Fri, Oct 16, 2009 at 4:48 PM, joneff jon...@gmail.com wrote: (off topic, or would it be May the Force extends your.prototype?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
Guys... (tapping shoulder)... um this is some pretty inconsequential
stuff that's being debated, wouldn't you say?
Just do Function.empty = Function.EMPTY = function() {};
(or just pick one)
Sorry, it really just doesn't matter vs. file size, modularity, performance,
features, (17 other facets I can't think of right now...).
---
Warm Regards,
Ryan Gahl
On Thu, Oct 15, 2009 at 4:22 AM, T.J. Crowder t...@crowdersoftware.comwrote:
Hey Andrew,
Aren't all functions constants, in that sense? Function.EMPTY isn't
more or less constant than Element.extend.
-- T.J. ;-)
On Oct 15, 1:08 am, Andrew Dupont goo...@andrewdupont.net wrote:
Weighing in again, decades after starting the thread.
First, I'm fine with calling it Function.IDENTITY instead of Function.K.
On Sep 25, 2009, at 1:26 AM, T.J. Crowder wrote:
Make sense. Shouldn't that be Function.empty and Function.k, though,
to follow our naming rules? And perhaps Function.k should have a more
meaningful name.
I'm very much in favor of all-caps, or at least initial caps, to
indicate that these are constants. We don't do this consistently in
the framework so far, but I'd like it to match stuff like
Event.KEY_ESC. I think the capitalization will also help distinguish
it from String#empty and Array#empty, as was mentioned elsewhere.
(Aside: I'm also in favor of renaming those methods to `isEmpty` for
2.0.)
What do people think about the capitalization?
Cheers,
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Palm's Mojo and Prototype
Hi Rob... AFAIK, in the bleeding edge SVN versions of Prototype, they are making use of the native JSON parsers if present. I could be wrong, but I believe I saw that somewhere. I'll leave it to one of the core dudes to comment further though... Ryan Gahl CEO Nth Penguin, LLC http://www.nthpenguin.com -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl On Tue, Mar 10, 2009 at 9:59 AM, Rob Tsuk robt...@gmail.com wrote: As you might have seen from some of Mitch Allen's webinarhttp://pdnblog.palm.com/?p=79, Palm's new Mojo application framework includes Prototype as part of its interface and implementation. As a member of the Mojo team, I'd like to extend thanks to all the Prototype library developers. Prototype gave us an enormous head start on developing Mojo. When we started Mojo we considered all the popular JavaScript libraries to use as a basis for Mojo. Prototype stood out for the large amount of needed functionality it added to JavaScript. I like to think that addition like those made to Array are functionality that Array classes should have, and it's odd that JavaScript omits them. Now that the details of webOS and Mojo are out in public, I have two questions about the design of Prototype whose answers would help in Mojo development. On a webkit-based browser, what is the reasons to create and use the event wrappers? In Mojo we've modified them to be thin wrappers around addEventListener for the short term to get around some memory leaks they caused in our environment, but I think that is too big and change and would like to find a more compatible fix. How much interest is there in augmenting Prototype to use a native JSON parser when present? Since we use JSON extensively in our system, the performance gains of a native parser are measurable. Our internal application developers have been using the Prototype JSON encoding/decoding features extensively, so it's best for Mojo if the Prototype JSON features used the native one. If the idea is appealing to the community, I'd happily provide a patch based on everyones notion of the right way to go about it. Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype and the global namespace
This pattern, which is a spin from the module pattern, allows many nice
things, including the use of truly private, class level, (static, protected,
etc) members. If you want to REALLY maximize performance and minimize the
overhead of the grossly overused .bind() function, you can identify instance
methods that really could be private static methods and move them into the
class module's global area, passing in the instance reference instead of
binding (thus, moving more towards functional looking code, but I still tend
to think of it as OO, where these become private static members of the
class).
To mashup kangax's pattern here with what I'm saying, and aim to just not
use bind if you don't have to (which is a Good Thing)... consider the
following slightly altered take(s) on kangax's code...
var Widget = Class.create((function() {
//protected, static methods
function init(widget) {
widget.element.observe('click', onClick);
//note, instead of using bind (which creates a copy of a function
anyway), we simply create the method in our desired scope (imagine that!)
function onClick() {
// ... now widget is the instance reference to use in here
}
}
return {
initialize: function(id) {
this.element = $(id);
init(this);
}
}
})());
...and yet another variation is to use the constructor as the place to, you
know... construct. I left the init() method at the static level for
illustration.
var Widget = Class.create((function() {
//protected, static methods
function init(config) {
config.widget.element.observe('click', config.onClickHandler);
}
return {
initialize: function(id) {
//early bind during construction:
var me = this;
//public properties...
this.element = $(id);
//private instance level methods... (replacement technique for using
.bind())
function onClick() {
// ... now me is the instance reference to use in here
}
//use the static init method, passing in our instance level onClick
handler (and of course the instance itself)...
init({
widget: this,
onClickHandler: onClick
});
}
}
})());
You'll notice that this pattern accomplishes several things. For starters,
it hides methods that really shouldn't be exposed as a public interface on
the instances anyway. The say that it's private in the comments or by
adding an underscore in front of it technique is just lazy and Bad Form. It
also avoids the overhead of using .bind() - which as you've discovered adds
up quickly. The true purpose of .bind() is just to create a copy of a
function, applied to the object you pass in. It is VERY convenient, and easy
to use (and mis-use). However, just creating the copy of your method in the
scope in which it is needed is all you have to do (no need for the
cleverness). Then, no $A() overhead, and debugging is straight forward, AND
you can truly hide members from calling code as appropriate... so while
you're seeming to move towards more functional code you're also actually
reaping _more_ of the benefits of OO.
It's a shift in thinking, but one that you'll grow to love if you make the
investment.
Ryan Gahl
CEO
Nth Penguin, LLC
http://www.nthpenguin.com
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
On Tue, Mar 10, 2009 at 2:14 PM, Rob Tsuk robt...@gmail.com wrote:
var Widget = Class.create((function(){
var bind = Prototype.lang.bind;
return {
initialize: function(id) {
this.element = $(id);
this.init();
},
init: function()
this.element.observe('click', bind(this.onClick, this));
},
onClick: function(){
// ...
}
}
})());
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $super keyword
I personally worry more about relying on non-standard behavior (i.e. function decompilation) Say what? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $super keyword
On Mon, Jan 5, 2009 at 11:23 AM, Ryan Gahl ryan.g...@gmail.com wrote: I personally worry more about relying on non-standard behavior (i.e. function decompilation) Say what? Oh, do you mean how the $super mechanism enumerates the method names and whatnot? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $super keyword
Yea, that's what I meant (I read the code when it was released and knew it was something weird like that). I agree, 'tis a hack... On Mon, Jan 5, 2009 at 11:48 AM, kangax kan...@gmail.com wrote: On Jan 5, 12:24 pm, Ryan Gahl ryan.g...@gmail.com wrote: On Mon, Jan 5, 2009 at 11:23 AM, Ryan Gahl ryan.g...@gmail.com wrote: I personally worry more about relying on non-standard behavior (i.e. function decompilation) Say what? Oh, do you mean how the $super mechanism enumerates the method names and whatnot? No, `$super` relies on parsing return value of `Function.prototype.toString` (when extacting argument names - and ` $super` in particular). This is non-standard functionality. Clients are free to return any function representation (including omitting argument names) when invoking `toString` on a function object. At least one browser (Opera mini) does that : ) -- kangax -- Ryan Gahl CEO Nth Penguin, LLC http://www.nthpenguin.com -- WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element wrapper draft notes
I like the wrapper tack (same way Ext does it). .raw doesn't sound intuitive
to me though. Why not just use .dom for the underlying element (also like
Ext)? Or .el? .raw just doesn't make for a beautiful API, IMHO :)
And no, don't make it a function call.
On Thu, Aug 21, 2008 at 10:41 AM, T.J. Crowder [EMAIL PROTECTED]wrote:
@JDD:
Thanks. I understood your suggsetion about the accessors, I thought
I'd also (separately) seen a suggestion that $$() return a single
wrapped element when it only finds one, but I'm not immediately
finding what it was that made me thing that. Sounds like we're all on
the same page wrt always returning a list. Apologies for muddying the
waters there.
I disagree on the list applying accessors to only the first element.
From an API perspective I just don't see that it makes sense. I'd
much rather see a first() method or property, or better yet (as I
suggested to kangax) an explicit means of saying give me the first
(and only the first) element that matches this CSS spec). If I see
the code list.highlight(), I'm going to expect the highlight method
to be applied to the list, not to the first entry on the list.
Now we could do this:
NodeWrapper.raw() - gives you the element;
NodeWrapper.raw(element) - sets the element;
and the internal var _raw is private;
We'll be using the raw underlying item a LOT, the last thing we want
to do is make accessing it a function call.
There would be no internal raw item for the NodeListWrapper because
like the jQuery object
its items are part of its indexed properties.
If it's not literally a wrapper, if it's a replacement, that's great
and it's certainly the simplest solution. But we keep calling it a
wrapper, which is the only reason for the question about indexed
access.
--
T.J. Crowder
tj / crowder software /
On Aug 21, 3:44 pm, John-David Dalton [EMAIL PROTECTED]
wrote:
@T. J. Crowder take some time to look at the jQuery source, it might
help with the wrapper discussion.
I was not suggesting that $$() return a list in some cases and a
single item in others. I was saying that
getter/setter methods would execute on the first matched item.
In jQuery (jQuery syntax):
$('#footer') - returns a jQuery instance (in our case it would be a
NodeListWrapper);
If you example the object it looks like:
NodeListWrapper[0] - div#footer (the html element)
NodeListWrapper.length - 1
NodeListWrapper.observe - method
NodeListWrapper.toggle - method
NodeListWrapper.each - method
NodeListWrapper._each - method
NodeListWrapper.show - method
NodeListWrapper.getValue - method
NodeListWrapper.update - method
the jQuery object and thus our NodeListWrapper will mimic an array,
it has a length, and index properties.
When you call a getter method then it executes on the first matched
item
NodeListWrapper.getHeight - execute on the first matched element and
not iterate over the list
NodeListWrapper.getStyle - execute on ...
NodeListWrapper.getDimensions() - ...
so $$W('#id').getHeight() - is the same as - $$W('#id')
[0].getHeight();
$$W('#id')[0] is an element in jQuery but if we wrap ours in a
NodeWrapper too then
$$W('#id')[0] would be the NodeWrapper
$$W('#id')[0] instanceof NodeWrapper would be true.
$$W('#id')[0].raw() would be the element,
now we can talk about if thats too many wrappers or what not,
but I think the approach of $$(selector)method is a good one.
Now we could do this:
NodeWrapper.raw() - gives you the element;
NodeWrapper.raw(element) - sets the element;
and the internal var _raw is private;
so that by the rules above if Prototype were modified $$W - $$, $W -
$
$('id').raw() - the element
$$('#id').raw() - the element (its a getter/setter so it executes on
the first matched)
$$('.panels').hide();
$$('.panels:first').hide();
$('myPanel).raw().tagName
$('myPanel).get('tagName');
There would be no internal raw item for the NodeListWrapper because
like the jQuery object
its items are part of its indexed properties.
- JDD
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Free a class from memory
Manually nulling the top level reference should work just fine, as long as
there are no other references to the object in other scopes. Another big one
to check is DOM event handlers... are you setting any up? If so, part of
your destroying should include unattaching them first...
On Thu, Jul 17, 2008 at 8:34 AM, kangax [EMAIL PROTECTED] wrote:
On Jul 17, 9:09 am, mtjs [EMAIL PROTECTED] wrote:
Hi,
I have something like this :
var myTestClass=Class.create({
initialize:function(opt) {
this.child=null;
// do stuff that uses mem
// like create and show divs
// and so on
},
myFnc:function(param) {
}
});
With this class I build a 'tree'.
(
in real life I use other code to do this : the child is assigned
from within the class, but that doesn't matter for my question
)
var myOne=new myTestClass();
myOne.child=new myTestClass();
myOne.child.child=new myTestClass();
myOne.child.child.child=new myTestClass();
I don't know how much childs there are, yet I want to free all the
memory.
Main question :
how can I do that ?
can I do it by : myOne=null;
should I free every instance ?
I tried it with a loop, first adding all childs to an array (if I
set the 'parent'
to 'null', I can't see what's in it anymore)
var emptyList=new Array();
var tmp=myOne;
while (tmp) {
emptyList.push(tmp);
tmp=tmp.child;
}
for (var i=0; iemptyList.length; i++) {
emptyList[i]=null;
}
This doesn't work: the 'reference' to the instance in 'emptyList[n]'
is a copy, not a
'reference' so I just use more memory and then empty it again, yet I
don't free the
tree I've made in 'myOne'. (so far as I tested)
can I destroy it from within 'myOne' (with a destory function or
something like that)
(I tried this=null in the class but that doesn't work ;))
All objects are actually passed by reference (including function
ones). Only primitives are copied. How exactly did you determine that
manual nulling doesn't work and only consumes more memory?
-- kangax
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Free a class from memory
When you do your stopObserving, you need to make sure you are passing the
exact function handler you used when registering the event.
var handler = function() { blah(); }.bindAsEventListener(this);
Event.observe(someElement, click, handler);
...later:
Event.stopObserving(someElement, click, handler);
NOTE: this is not going to work:
Event.observe(someElement, click, function() { blah();
}.bindAsEventListener(this));
Event.stopObserving(someElement, click, ???); //notice I don't have a
handle to that anonymous function I defined above so I can't stop observing
it
On Thu, Jul 17, 2008 at 9:45 AM, mtjs [EMAIL PROTECTED] wrote:
Thanx for the replys.
I am setting up event handles with 'observe'. I also use
bindAsEventListener.
Isn't it enough to do a 'stopObserving' on the events ?
To know if I have a 'memory leak' (and to determing that the null'ing
didn't work) I look @ the ... memory the browser is using. If it goes
up, I have a leak. (if I add nothing to the page ofcoz :)) If I null
the top reference, I have lesser memory that is added then if I don't
do it, but since there was still mem addes, I figured it wasn't
enough.
Is there some kind of documentation on what you should watch to not
create memory leaks ? Also is there some kind of tool to correctly see
if you have memory leaks?
Kind regards,
Mtjs.
On Jul 17, 3:44 pm, Ryan Gahl [EMAIL PROTECTED] wrote:
Manually nulling the top level reference should work just fine, as long
as
there are no other references to the object in other scopes. Another big
one
to check is DOM event handlers... are you setting any up? If so, part of
your destroying should include unattaching them first...
On Thu, Jul 17, 2008 at 8:34 AM, kangax [EMAIL PROTECTED] wrote:
On Jul 17, 9:09 am, mtjs [EMAIL PROTECTED] wrote:
Hi,
I have something like this :
var myTestClass=Class.create({
initialize:function(opt) {
this.child=null;
// do stuff that uses mem
// like create and show divs
// and so on
},
myFnc:function(param) {
}
});
With this class I build a 'tree'.
(
in real life I use other code to do this : the child is assigned
from within the class, but that doesn't matter for my question
)
var myOne=new myTestClass();
myOne.child=new myTestClass();
myOne.child.child=new myTestClass();
myOne.child.child.child=new myTestClass();
I don't know how much childs there are, yet I want to free all the
memory.
Main question :
how can I do that ?
can I do it by : myOne=null;
should I free every instance ?
I tried it with a loop, first adding all childs to an array (if I
set the 'parent'
to 'null', I can't see what's in it anymore)
var emptyList=new Array();
var tmp=myOne;
while (tmp) {
emptyList.push(tmp);
tmp=tmp.child;
}
for (var i=0; iemptyList.length; i++) {
emptyList[i]=null;
}
This doesn't work: the 'reference' to the instance in
'emptyList[n]'
is a copy, not a
'reference' so I just use more memory and then empty it again, yet
I
don't free the
tree I've made in 'myOne'. (so far as I tested)
can I destroy it from within 'myOne' (with a destory function or
something like that)
(I tried this=null in the class but that doesn't work ;))
All objects are actually passed by reference (including function
ones). Only primitives are copied. How exactly did you determine that
manual nulling doesn't work and only consumes more memory?
-- kangax
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLChttp://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog:http://www.someElement.com
LinkedIn Profile:http://www.linkedin.com/in/ryangahl- Hide quoted text -
- Show quoted text -
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: C and PHP style syntax to fill an array with values
See... confusing eh?
:)
but, perhaps funkyTown sets davidHasselhoff to {USA: {fans: [4]}, Germany:
{fans: [9993]}}
On Wed, Jul 2, 2008 at 12:58 AM, Gareth Evans [EMAIL PROTECTED] wrote:
I think you'll find that method has a fatal flaw,
You'll lock the browser up because davidHasselhoff is always false.
Gareth
On Wed, Jul 2, 2008 at 5:43 PM, Ryan Gahl [EMAIL PROTECTED] wrote:
No, Jerod... this is the most confusing way ever (note: theMeaningOfLife
is declared elsewhere):
var array = new Array();
function adamSandler(georgeCostanza) {
var whatTheF = 42;
array[-whatTheF + theMeaningOfLife] = georgeCostanza;
}
var ryanSeacrest = isTodayTuesday() ? 41234522 : 0;
while (!davidHasselhoff) {
adamSandler(funkyTown(ryanSeacrest)); //where is this funkyTown method?? I
want someone to take me to funkyTown! Won't you take me to funkyTown?
}
Agreed?
(yes, i'm tired atm)
On Tue, Jul 1, 2008 at 8:41 PM, Jerod Venema [EMAIL PROTECTED] wrote:
That has to be the most confusing way to fill an array EVER.
On Sun, Jun 8, 2008 at 8:17 PM, tancurrom [EMAIL PROTECTED]
wrote:
It's interesting to note that in JavaScript version 1.7, array
comprehensions allows you do achieve this kind of 'filling' of your
arrays.
E.g.
function range(begin, end) {
for (let i = begin; i end; ++i) {
yield i;
}
};
var n = [0 for each (i in range(0,20))]
// [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
info from: http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
On Jun 8, 2:44 am, Jay Tee [EMAIL PROTECTED] wrote:
On Jun 3, 10:06 am, Yanick [EMAIL PROTECTED] wrote:
Hope this helps. (And if the core folks think this is core worthy, I
think it could make a pretty addon.)
yanick
You've helped very much! This particular function has helped me with
populating grids more than anything else. It's so much easier to fill
an array like this than loop or use a literal; especially for
particularly long arrays :)
Jon
--
Jerod Venema
Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
(919) 368-5105
---
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com http://www.someelement.com/
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: C and PHP style syntax to fill an array with values
No, Jerod... this is the most confusing way ever (note: theMeaningOfLife is
declared elsewhere):
var array = new Array();
function adamSandler(georgeCostanza) {
var whatTheF = 42;
array[-whatTheF + theMeaningOfLife] = georgeCostanza;
}
var ryanSeacrest = isTodayTuesday() ? 41234522 : 0;
while (!davidHasselhoff) {
adamSandler(funkyTown(ryanSeacrest)); //where is this funkyTown method?? I
want someone to take me to funkyTown! Won't you take me to funkyTown?
}
Agreed?
(yes, i'm tired atm)
On Tue, Jul 1, 2008 at 8:41 PM, Jerod Venema [EMAIL PROTECTED] wrote:
That has to be the most confusing way to fill an array EVER.
On Sun, Jun 8, 2008 at 8:17 PM, tancurrom [EMAIL PROTECTED]
wrote:
It's interesting to note that in JavaScript version 1.7, array
comprehensions allows you do achieve this kind of 'filling' of your
arrays.
E.g.
function range(begin, end) {
for (let i = begin; i end; ++i) {
yield i;
}
};
var n = [0 for each (i in range(0,20))]
// [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
info from: http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
On Jun 8, 2:44 am, Jay Tee [EMAIL PROTECTED] wrote:
On Jun 3, 10:06 am, Yanick [EMAIL PROTECTED] wrote:
Hope this helps. (And if the core folks think this is core worthy, I
think it could make a pretty addon.)
yanick
You've helped very much! This particular function has helped me with
populating grids more than anything else. It's so much easier to fill
an array like this than loop or use a literal; especially for
particularly long arrays :)
Jon
--
Jerod Venema
Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
(919) 368-5105
---
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype vs Ext
Ext is a full featured component library. The only issue with it (for some) is going to be fact that it's a commercial product more than it is open source (you can use it for free but only if you are releasing your stuff as open source). If you are building a major browser based application intended to run as a single page, long running app (think full featured desktop-like app in the browser), and you are planning to make money with it or are in an enterprise setting and can't release your app as open source, then Ext is (as I said) MORE than worth the VERY small price they are charging. Trust me, whoever said it's nothing more than an abstraction layer is a) wrong and b) just not using Ext to its fullest potential. Prototype is an abstraction layer (OO and cross browser DOM manipulation). Ext _can_ be used with many other frameworks/libraries, including prototype. If you use it in this manner, Ext _does_ smartly utilize facilities from those libraries, assuming that that is why you chose to use both. If all you want are a couple of semi rich widgets to go into a low or no budget project, that you or your client are trying to make money with, don't use Ext. If you are building a full blown browser app that needs to have a polished look, work across browsers, and that looks and feels like a desktop app, than don't use anything other than Ext (it's by far your best choice). nuff said :) On 6/17/08, Ken Snyder [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2008 at 5:42 PM, Franck PORCHER [EMAIL PROTECTED] wrote: ... In a few words, and in whatever spare time you Core guys might have, what is the story behind these 2 frameworks, if any, how do they compare in the long run of javascript programming (if any kind of comparison was ever attempted), and how do you foresee the future of both. Franck PORCHER www / smartech / pf A good friend of mine uses Ext because he writes applications that must work with YUI, dojo, /and/ Prototype. Using Ext allows him to write code that will work with any of those libraries. He describes it as an abstraction layer above a framework. As an abstraction, it makes sense that each Ext feature would be limited by the library with the weakest implementation of that particular feature. - Ken Snyder -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: New Name for Users Group (RoR Spinoffs)
My vote is for Super Thunderbots Attack Squadron 3000 If no one votes for that though, I'd settle for Prototype and Scriptaculous Users On 6/17/08, T.J. Crowder [EMAIL PROTECTED] wrote: Hi folks, I've been chatting today with Tobie about renaming / replacing the RoR Spinoffs mailing list (there's a thread about it over there[1]). Rationale and discussion over there, but the short version is that pretty much everyone agrees we should do it, and so Tobie and I were talking about mechanics and transition. So we need to think of a new name. I made a suggestion in the thread, I made a suggestion that no one really commented on either way. I'll revise it slightly: My suggestion is Prototype and Scriptaculous Users ([EMAIL PROTECTED]). Boring, but fairly clear. Tobie suggested we should discuss the name here. What do you think? Better ideas? -- T.J. Crowder tj / crowder software / com [1] - http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/0732340bedfdd74b# -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype vs Ext
Long story short, I have been using both for almost as long as either of them have been around. Basically, Prototype provides a wonderful OO abstraction facility and DOM manipulation sugar, while Ext gives you a full set of excellently designed UI components. Ext's OO model is not as robust as Proto's. My biggest message to you would be that they are _not_ mutually exclusive, and in fact work very well together. On 6/17/08, Franck PORCHER [EMAIL PROTECTED] wrote: Hi, I just got on Ext and I'am studying its API out of sheer curiosity because I like its out-of-the-box UI facilities. It looks to me that Ext borrowed lots of things from Prototype, remixing the whole thing under its own kind of syntactic sugar layer, somehow less intuitive than Prototype. In a few words, and in whatever spare time you Core guys might have, what is the story behind these 2 frameworks, if any, how do they compare in the long run of javascript programming (if any kind of comparison was ever attempted), and how do you foresee the future of both. Franck PORCHER www / smartech / pf -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype vs Ext
Your prices are a bit off, as you're citing the with full support prices. The vanilla pricing is $289, $1159, $4,999, and $14,449 respectively... And here's their high level explanation of when you have to pay for it: Based on the Quid Pro Quo principlehttp://www.extjs.com/company/dual.php, if you wish to derive a commercial advantage by not releasing your application under an open source license, you must purchase an appropriate number of commercial licenses from Ext. By purchasing commercial licenses, you are no longer obligated to publish your source code. So yes... it depends on what you're doing. If you are doing something commercially, and have a viable product/vision/market though, those prices are MORE than reasonable for the level of framework that is Ext. Anyway... sort of apples to oranges, as Proto is a baseline that handles OO abstraction, Ajax, and DOM manipulation in a cross browser manner, and Ext is more of a component library. On 6/17/08, Jon L. [EMAIL PROTECTED] wrote: On Jun 17, 6:42 pm, Franck PORCHER [EMAIL PROTECTED] wrote: In a few words, and in whatever spare time you Core guys might have, what is the story behind these 2 frameworks, if any, how do they compare in the long run of javascript programming (if any kind of comparison was ever attempted), and how do you foresee the future of both. Franck PORCHER www / smartech / pf Not sure what everyone else thinks. But, a good starting point might be: Prototype is free to use. Sure, Ext can be free, but only for free software projects (GPL3). Corporate licensing runs $540 for developer, $2000 for team, $7130 for workgroup, or $18,700 for enterprise. ...well, my wallet's screaming in pain! - Jon L. -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Can the Enumarable iterators be changed to accept scope as the first param (optionally)
Completely disagree. First of all, you don't need the parentheses in your
first example. You can simply do stuff like function() {...}.bind(this).
Secondly, in your conclusion you are assuming that you will always _need_ to
correct scope, when in fact you only need to do this if you want to use the
keyword this within the iterator. There are many times when you would not
be correcting scope at all, so then are you suggesting that we pass in null
as the first param?
Thirdly, and most importantly... just create a wrapper if you want this
syntax... and get used to creating wrappers where you want/need a new API.
//cache old method for calling within the override
Array.prototype._oldEach = Array.prototype.each;
Array.prototype.each = function(scope, iterator) {
if (scope)
iterator = iterator.bind(scope);
return this._oldEach(iterator);
};
.bind(this) is not ugly by the way. It's a very elegant solution, and IMHO
you'd be better served just getting used to it as you will see it in any
prototype user's work, should you ever be part of a bigger team.
On 2/7/08, sambo99 [EMAIL PROTECTED] wrote:
I blogged about this issue here:
http://www.samsaffron.com/archive/2008/02/09/A+cleaner+way+to+iterate+through+Enumerable+lists+in+Prototype
I think iterators look nicer when you have the scope as the first
param.
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Can the Enumarable iterators be changed to accept scope as the first param (optionally)
Keep in mind also... I'm just one vote. I can't tell you how many times I've been outvoted here :) -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Source code style
This is all stuff you learn to grok quickly as you gain javascript experience. When you think in closures, only then can you attain inner peace :) -1 here... keep it concise. On 10/4/07, Sven Klose [EMAIL PROTECTED] wrote: I´m new to the source code, and had big trouble reading it. With the right indentation one could spot constructs immediately, but actually, the code is so compressed, it takes ages to even figure out where a function starts and where it ends, to spot if-statements and variable declarations, and so on. Some suggestions in detail: - dedicate a whole line for an opening/ending brace of a function if it doesn't contain just one statement, - keep the width of lines small, - declare only a single variable in a var-statement, - have indented conditional blocks, instead of squeezing an if- statement into a single line, - use distinct variable names, not 'Method' and 'method' in the same function for example, - use TABs, so all this all can be done without increasing the code size, and one can set the indentation width to suit his/her needs, - add more comments :) Your visual perception can spot the overall structure of code at once. Please keep it stupid for the likes of me. ;) I'd do the reformatting, if desired. However, I find the use of spaces and empty lines very good already. Best regards. -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Superclass constructor
Oh yea... it's definitely not a core thing as it depends on an app's object and domain model. This was kind of just an aside conversation that popped up I think :) On 9/28/07, Nicolás Sanguinetti [EMAIL PROTECTED] wrote: I'm not gonna say to you that if you have something complex calling destructors isn't correct. I'm just gonna argue against it being in core, as IMHO it's something that not really many people need, and, since you have to call it manually, the best you can do is defining a naming convention, not a behavior. So do it if you want it, I'm not one to tell you what methods you can or cannot call on your projects :) Best, -Nicolas On 9/28/07, Ryan Gahl [EMAIL PROTECTED] wrote: Alex, javascript has its own garbage collector, sure... but firstly, it's not a consistent implementation across browsers. This is an ancient problem as far as Ajax development goes. Secondly, the apps I develop (and more people are starting to get into) are highly complex, long running single page apps (major applications running in a browser, not enhanced websites), with widgets coming in and out of existence as the user interacts and moves through the flow of the app. The dispose methods handle 1) removing dom event handlers from dom elements before they are removed from the dom, therefore removing that as a memory leak path (which is a very well documented path, look it up), 2) destroying children widgets it may have created during its lifetime, unregistering things like Draggables, Sortables, etc... 3) any other actions required during the dispose cycle, like persisting or hydrating state in cases where it's important. Your trying to tell someone that's been doing Ajax development for 3+ years that he doesn't know what he's talking about... simma down, nah! On 9/28/07, Alex Arnell [EMAIL PROTECTED] wrote: On Sep 24, 1:16 pm, Les Szklanny [EMAIL PROTECTED] wrote: Yes, the destructor needs to be called manually, but calling it eliminates possible memory leaks. See below a destructor for the marker (pin) object that you see on a map. This destructor also destroys the events object, which is a property of marker. You guys are taking this way way too far. Javascript is a language in of itself. It has it's own rules and ways of doing things. The core team has merely added a more convenient way to do OO operations. They aren't re-inventing the wheel, or doing anything that wasn't already possible with the language. Secondly, javascript uses automatic garbage collection. There is no need to create destructor methods, the javascript engine will clean up un-referable objects at some future time. Granted, there are a few caveats especially when dealing with Closures but those are all things that documented and things that are common to other languages that use automatic garbage collection. Have a look here if you don't believe me. http://jibbering.com/faq/faq_notes/closures.html#clAtGb -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Class.create and inheritance
indeed! Sorry again for jumping the gun - sort of a vanity thing there I guess (ooo, ooo, use my code, use my code), :) At least one thing I do like about your implementation is the shortcut syntax for supplying the subclass definition right within the Class.create() call. When I have time I think I'll borrow that idea and apply it to my Object.inherit implementation to get rid of a line of code. On 9/27/07, Mislav Marohnić [EMAIL PROTECTED] wrote: On 9/27/07, Ryan Gahl [EMAIL PROTECTED] wrote: ok, then it does work, my apologies :) Every implementation breaks if you use it wrong. -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
I vote an emphatic No - this would be overhead within proto-core, which
should remain as _baseline_ as possible (that's my rant and I'm sticking to
it - proto is a baseline - don't bloat it... please!). What people need to
get in the habit of doing is loading an extensions.js file (or something)
after proto (or lib-of-choice)... and do whatever overriding/wrapping there.
Your case in point...
var oldInsert = Element.insert;
Element.insert = function(...) {... fireYourCustomEvent() ...
oldInsert(...)};
On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I had an interesting thought while testing out version 1.6 RC - I
thought I'd solicit some opinions (and possibly make a suggestion).
There is not a very reliable cross-browser way to implement the DOM
mutation events - (such as DOMNodeInserted, DOMNodeRemoved,
DOMAttrModified, etc). However, using custom events, it should be
possible to register listeners for equivalents and send those events
in prototype calls, such as Element.insert, etc.
That would allow for some pretty powerful dynamic things - that can
observe DOM change events. 1.6 already spoofs one of those events
in the contentloaded event...it would be pretty cool to add a bit
more support for others as well...
What are peoples' thoughts on this? Or would it better be implemented
outside of prototype (I can't think of a way to piggyback on the
already-existing functions without writing wrapper functions and
extending thingspossible, but it seems a bit cleaner to support it
natively within prototype itself.
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Superclass constructor
Les, everyone is correct in stating there are inherent problems (or issues to be aware of) with multiple inheritance. However, it is certainly handy when you really need it (and know what to be careful of). Again, feel free to check out the inheritance model I use ( http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html), as it does support multiple inheritance as well. There are also some issues I have with the whole prototype-static, instance methods vs. true instance only methods, so I do away completely with forcing references to the superclass methods. You need to call a superclass method within an overridden subclass method - just grab the reference on your own (explained in that blog post). The prototype-core team's job is to handle at least 85% of people's needs. AFAIK the new inheritance stuff achieves that (though using my model I will have no needs for it)... we just need to keep in mind that if we run into our own needs, or edge cases, we can mod away (just remember to do it smartly to not break your upgrade path). On 9/22/07, Nicolás Sanguinetti [EMAIL PROTECTED] wrote: On 9/22/07, Les [EMAIL PROTECTED] wrote: The OpenLayers API 2.5 (a maping API in part based on Prototype) supports multiple inheritance, so why not Prototype? Mislav said: Also, multiple inheritance isn't all that good. There is a reason Java and C++ successors like Objective-C and C# chose not to support it. JavaScript 2.0 looks like it will not support it either. So, it's a design goal not to have multiple inheritance. Besides, we all heard composition is better than inheritance :) Instead of rigidly inheriting from multiple sources, just delegate behavior to other objects. It's *that* simple. And it's effective too ;) Or use dojo, or OpenLayers, or whatever else you fancy :) Best, -Nicolas -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Superclass constructor
I use something similar in WebWidgetry's object model (dispose in my case
instead of destroy)... never saw OpenLayers.
On 9/24/07, Les [EMAIL PROTECTED] wrote:
Ryan,
Did you notice that each OpenLayers class has a destructor (destroy)
and a property denoting the class name?
I don't see such a destructor in Prototype or Dojo, see below:
OpenLayers.Map = OpenLayers.Class({
initialize: function (div, options) {
},
destroy:function() {
},
CLASS_NAME: OpenLayers.Map
});
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Superclass constructor
via the object model abstraction layer we have in our framework - so at that
level it's a manual call, but by using the framework it's managed and for
all intents and purposes automatic via a custom app garbage collector. Then
again, we have an XML layer to represent widgets as finite state machines
and manage application flow declaratively - so I'm talking about quite a few
levels removed from the average prototype application...
Just because js doesn't support something doesn't mean it's not possible.
It's all about abstraction of common tasks.
Basically, you want to start by creating something like a Disposable
abstract class that your objects inherit from (or an interface that they
implement) that includes a dispose() method (we use interfaces here for
true contractual development)... then you implement the specific dispose
logic on a per class basis to cleanup resources. Then, yes, at first it's a
manual process of making sure dispose() gets called when it needs to be
called. If you end up, like we often do, following a progression of
abstracting away common tasks as you get sick of doing them over and over
again manually, you eventually end up with some type of automatic garbage
collection (that still assumes a dispose method exists on the object public
interface).
On 9/24/07, Jeff Watkins [EMAIL PROTECTED] wrote:
How would you implement a destroy or destructor function since
JavaScript doesn't support it? Do you manually call the method?
On Sep 24, 2007, at 11:24 AM, Les wrote:
Ryan,
Did you notice that each OpenLayers class has a destructor (destroy)
and a property denoting the class name?
I don't see such a destructor in Prototype or Dojo, see below:
OpenLayers.Map = OpenLayers.Class({
initialize: function (div, options) {
},
destroy:function() {
},
CLASS_NAME: OpenLayers.Map
});
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Element.update() speed boost
+1 for baking this into core, it's like duh, how no one tested this before On 9/13/07, jdalton [EMAIL PROTECTED] wrote: Hi all, I was just reading on ajaxian that Steven Levithan has done some benchmarks and found that innerHTML's main bottle neck is in its destruction of existing nodes/elements. He has posted a new method. He has benchmarks and a performance test as well. I figured it would be an interesting addition to Element.update(). http://blog.stevenlevithan.com/archives/faster-than-innerhtml Anyone interested? -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element.update() speed boost
You'd be losing attached event observers anyway when you do a plain old
.innerHTML = ...
If anything, a one-step further implementation of this method would handle
_removing_ any event handlers for you for memory management considerations
(addressing potential circular reference based leaks that you would/should
be dealing with manually anyway)
On 9/13/07, Tom Gregory [EMAIL PROTECTED] wrote:
Is there a gotcha with this code? (I haven't tested, and defer to
brighter minds than mine.)
Because he's replacing the target node with a clone of itself (code
below), is there the potential to lose attached event observers? That'd
violate POLS.
/* This is much faster than using (el.innerHTML = value) when there are
many
existing descendants, because in some browsers, innerHTML spends much
longer
removing existing elements than it does creating new ones. */
function replaceHtml(el, html) {
var oldEl = (typeof el === string ? document.getElementById(el) : el);
/[EMAIL PROTECTED] // Pure innerHTML is slightly faster in IE
oldEl.innerHTML = html;
return oldEl;
@*/
var newEl = oldEl.cloneNode(false);
newEl.innerHTML = html;
oldEl.parentNode.replaceChild(newEl, oldEl);
/* Since we just removed the old element from the DOM, return a reference
to the new element, which can be used to restore variable references. */
return newEl;
};
TAG
On Sep 13, 2007, at 9:01 AM, Ryan Gahl wrote:
um, oops: duh, how _come_ ... (missed a word)
On 9/13/07, Ryan Gahl [EMAIL PROTECTED] wrote:
+1 for baking this into core, it's like duh, how no one tested this
before
On 9/13/07, jdalton [EMAIL PROTECTED] wrote:
Hi all,
I was just reading on ajaxian that Steven Levithan has done some
benchmarks and found that innerHTML's main bottle neck is in its
destruction of existing nodes/elements. He has posted a new method. He
has benchmarks and a performance test as well. I figured it would be
an interesting addition to Element.update().
http://blog.stevenlevithan.com/archives/faster-than-innerhtml
Anyone interested?
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Bug?
This technique is also used in Extjs. It covers most cases, sure. However, it potentially fails in situations where resource lazy loading is used heavily. In our widget framework, each widget is responsible for encapsulating its own resource requirements, so it sometimes possible to have code like this loaded well after the initial page was loaded (for instance, the app did not consume a widget at startup that required Ext or proto, hypothetically, but does at some later point). So... what happens is this document.write is called within a context where the DOM has already been loaded. There should just be some simple check for the state of document.body before even going through this step (if DOM loaded document.body exists), and just do the notify immediately in that case. Resource lazy loading is increasingly important as the complexity of an application (read: not website with minor ajax enhancements) increases, and now both Ext and proto require me to do some fairly hackish stuff with redefining document.write to account for these situations). On 9/6/07, jdalton [EMAIL PROTECTED] wrote: I forgot to mention that without that little trick on an HTTPS site in IE you get an ugly warning dialog... -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
-1 for identify (we're not talking about the act of identifying something,
but generating a unique id)
-1 for making it an instance method on elements (see my last post for
reason)
+1 for getId
+1 for static method only (Element#getId)
Actually, this should really be so general as to not even be specific to
Element(s)... just a good old general purpose method will do.
+1 for pulling out to a general level
and of course,
+1 for allowing the dev to supply the prefix
...
+100 for whatever you decide to actually implement, because you're the one
doing the work :-)
On 7/18/07, Tobie Langel [EMAIL PROTECTED] wrote:
Hi all,
Don't know what's up with the google groups today... I posted an
earlier message which hasn't appeared anywhere yet.
Anyway, this is just to advise you that I posted a patch:
http://dev.rubyonrails.org/ticket/9012
I went with identify as a method name as I thought it's definition
(establish or indicate who or what (someone or something) is) nicely
fit what the method does and clearly refers to the id attribute.
Obviously, that's still still open for discussion.
Also, I didn't implement the scoping some of you suggested, but if
there's a real use case for it, implementing it is trivial, so please
speak up.
Regards,
Tobie
On Jul 18, 10:57 am, Ken Snyder [EMAIL PROTECTED] wrote:
Tobie Langel wrote:
...
I'm also concerned about naming the method adequately. Sam suggested
Element#denominate which looks nicer than (generate|assign)Id but
which I fear could be confused with setting the name attribute. The
only other option I came up with is Element#identify. Thoughts on this
issue ?
Also, I'm wondering whether the method should return the element - for
chaining purposes and to follow the general pattern of the other DOM
methods - or the generated id itself, which IMHO would proove more
useful here. Again, what are your thoughts ?
Thanks for your valuable input,
Tobie
The function seems more useful if it returns the id. I'd vote for the
name Element#getId(). Then you can call the function and always get an
id back regardless of whether the element has an id already. I like
Jeff Watkin's exact implementation. I think that the namespacing idea
is interesting but an edge case--creating groups of elements is as easy
as creating a hash:
{group1: [el1, el2, el3], group2: [el4, el5, el6]}
- Ken
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
If this does make it to core, I would then also suggest allowing the developer to specify the prefix of the ID (default to uniqueId). Optionally, go so far as to track a separate incremented value per new prefix, allowing the dev to essentially set up element groups. This would be considered like namespacing the ids. So you just need one more small step to store a hash of prefixes and their corresponding current _nextUniqueId values. On 7/14/07, Sam Stephenson [EMAIL PROTECTED] wrote: On Jul 14, 2007, at 1:32 PM, Tobie Langel wrote: I'm failing to see what advantage it has over directly storing a reference to the element like so: this.myElement = $(e); ... var e = this.myElement; I'm using a similar technique in a couple of applications where I needed to cache references to parent nodes of certain elements. In order to avoid circular references, the parent nodes' IDs are stored in custom attributes and dereferenced with $(). It's not always convenient to give those nodes IDs in HTML, so I settled an Element#denominate method that assigns IDs if they don't exist using a string prefix + new Date().getTime(). (I do like Jeff's suggestion of using an auto-incrementing value instead of a timestamp.) It's a good fit for core, IMO. -sam -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
my vote is #1
It is up to the devs to a) use the name and id attributes properly, and b)
wrap anything you want any way you want in some custom wrappers file that
you load in after prototype (or whatever library it is you are creating the
wrapper for).
For instance, I have never had this problem, nor do I think I ever will (if
an element i want does not have an id, I can either add one or get the
reference via some other selector on a case by case basis -- basically the
name attribute has no value to me whatsoever)... but if I had this need I'd
know I can just rely on the mutable nature of javascript and redefine the
$() within my app to behave however I want.
If this type of change _does_ make it into prototype, it would be an
addition of unnecessary code, IMHO.
On 6/18/07, Adam McCrea [EMAIL PROTECTED] wrote:
So sorry to beat this dead horse, but I just want to weigh in my thoughts
on this before it gets shot down. I agree that $ should only be a light
wrapper around getElementById, but unfortunately getElementById is broken
across browsers. I'm surprised to hear that you think the fix is heavy. In
my eyes it is a lightweight fix to save some major headaches for those who
don't have control over the HTML source.
My vote is for #2!
- Adam
On 6/18/07, Andrew Dupont [EMAIL PROTECTED] wrote:
On Jun 18, 2:01 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
My vote is for #1. The $ function is intended to be a light wrapper
around document.getElementById . The impulse is noble to want to
correct IE's incorrect behavior (and Opera's emulation thereof), but I
think it's just a little too heavy.
Cheers,
Andrew
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: To make Object.extend() support methods named 'toString'
Then this opens up the whole can of worms of, well if we're adding explicit
support for this non-iterable property, why not others, and the list could
grow along with any resulting code.
If anything, I'd add support for passing an array of member names to check
for at extend-time (thus making it extensible)... but I'm not thinking
changing Object.extend is the level to do any of this.
I'm all about leaving the core as just that, _core_ functionality, and
leaving it to the devs using it to override or put any kind of wrappers they
want around the functions.
For instance, in this case:
var oldExtend = Object.extend;
Object.extend = function(destination, source) {
if (source.toString) {
//add support for copying toString()
destination.toString = source.toString;
}
return oldExtend(destination, source);
}
On 5/30/07, Mislav Marohnić [EMAIL PROTECTED] wrote:
On 5/30/07, jdalton [EMAIL PROTECTED] wrote:
I was looking through some of my old source code and noticed that I
added a modified Object.extend method.
Apparently the normal for-in loop used in the Object.extend guts
ignores methods named 'toString'.
Yeah, toString is non-iterable in JS. But before applying this we must
make sure it doesn't break anything!
I'm kinda reluctant to even consider chaning Object.extend.
--
Ryan Gahl
Principal, Manager
Nth Penguin, LLC - Consulting
http://www.nthpenguin.com
--
Software Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Question/Suggestion
Also, check out:
http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html
This is my rendition of Kevin Lindsey's inheritance model, designed to
support multiple inheritance and play well with prototype.js
For what you're talking about, read the section near the bottom labeled So
how can you override base class methods and make sure that the original base
class method still gets called?
Object.extend works very well as a simple bulk property copying mechanism,
and as such does not need this extra jazz. I really think you're looking for
a true inheritance model, which Object.extend has never been, nor really
should be morphed into, IMHO.
On 5/4/07, Jerod Venema [EMAIL PROTECTED] wrote:
Greetings!
Nice bit of code there! You may want to check out this:
http://www.ivy.fr/js/extend/index.html
if you're going down that road anyway...
-Jerod
On 5/4/07, Tomasz R. [EMAIL PROTECTED] wrote:
Hi,
I've recently started using prototype.js, but I've been doing AJAX
for long time now.
I've inspected the prototype.js code, and I think I've got an
interesting addition to the Object.extend.
I might have reinvent the wheel here, so if it's nothing new please
give me some pointers as to how to accomplish the same with the native
prototype.js code.
Basically, I was looking for a way to call the original function of an
extended object. Here is my modification:
// a new version of extend
Object.extend2 = function(destination, source) {
for (var property in source) {
if(destination[property]) {
if(!destination['__super']) {
destination['__super'] = {};
}
destination['__super'][property] =
destination[property];
}
destination[property] = source[property];
}
return destination;
}
// code to be executed to see the behavior.
var a = Class.create();
a.prototype = {
initialize: function(name,link) {
this.elements = new Object();
},
test: function() {
alert('hello');
}
}
var b = Class.create();
b.prototype = Object.extend2(new a(), {
initialize: function() {
},
test: function() {
this.__super.test();
alert('hello2');
}
}
)
var B = new b();
B.test();
// END
after executing this code, you should first see the hello alert, and
then hello2.
I think this is an interesting addition, since I find myself often in
need to be able to access methods of the original object, without
having to copy/paste it's behavior to the new one.
--
Ryan Gahl
Software Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Curry And Compose
I think I am still expecting the bind operation to be applied to the subject of this sentence, that is, function a, not b. I would expect the bind to apply to whatever the result is of the compose (or any other) method, not the object to which the method belongs. In your example you are implying that the result of a.compose(b) is a function, which you are then binding c to. That makes sense, but not what you said. If you wanted c bound to a and then composed with b you'd need a.bind(c).compose(b) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: adding $parent to Object.extend
However, you could employ a slightly more traditional approach, which is to
leave the first version of A as the base class, and then subclass it as
needed:
(Btw, the way you have written A below is as a static object, and as such
you are gaining nothing by using Class.create(). Class.create() points the
constructor for the class at an initialize method on the class's
prototype, which of course you never define)
Try something like this (notice that I define public class level instance
methods within the constructor to ensure they are truly only given to
instances of the class):
var A = Class.create();
A.prototype = {
initialize: function() {
//public instance members
this.show = function() {
alert(I am A);
};
}
}
var B = Class.create();
Object.inherit(A, B);
Object.extend(B.prototype, {
initialize: function() {
//base class construction
this.base();
//override show
var oldShow = this.show.bind(this);
this.show = function() {
oldShow();
alert(I am EXTENDED A);
};
}
});
var test = new B();
B.show(); // alerts I am A and I am EXTENDED A
This technique comes right from by blog post on the inheritance model.
Now, if you're looking to tack (or override) methods on existing
instances... you don't need a special addPlugin() method like what you
started doing. You can just take advantage of plain old javascript...
(Assume we are back to using the definition of A from your original post)...
var oldShow = A.show.bind(A);
A.show = function() {
oldShow();
alert(I am EXTENDED A);
};
Notice in my first example (the object oriented approach), and in this
example (the static object version) I use a .bind() call. Doing so ensures
that if A.show() ever tried to access this, it would still point to the
correct scope.
For instance, imagine A.show() looked like this:
function() {
alert(this.name);
}
Ok... so I'll stop now I guess, just realize this list isn't really supposed
to be a support list. :-)
Hope this has helped though.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: adding $parent to Object.extend
You're really going the long way around to achieve something that's quite
simple. See my last reply in this thread.
On 3/30/07, Lorderon [EMAIL PROTECTED] wrote:
Hi,
The point was to extend the original object with reference to the
parent object (the original object as before the extension), and
without creating a new class/object inherited from the original one.
I solved my problem with this:
addPlugin: function(pluginObj) {
var $parent = Object.clone(this);
for (var p in pluginObj) {
if (typeof(pluginObj[p])=='function')
pluginObj[p] = eval(pluginObj[p].toString());
}
Object.extend(this,pluginObj);
}
Notice the addPlugin method defines the $parent object, then it re-
evaluates the methods in the extension object (pluginObj).
Wouldn't it better if you could access the parent via a special object
$parent.show() rather than making:
this.show.bind(this)();
Where can I find the support forum?
-thanks, Eli
On Mar 30, 4:52 pm, Ryan Gahl [EMAIL PROTECTED] wrote:
However, you could employ a slightly more traditional approach, which is
to
leave the first version of A as the base class, and then subclass it as
needed:
(Btw, the way you have written A below is as a static object, and as
such
you are gaining nothing by using Class.create(). Class.create() points
the
constructor for the class at an initialize method on the class's
prototype, which of course you never define)
Try something like this (notice that I define public class level
instance
methods within the constructor to ensure they are truly only given to
instances of the class):
var A = Class.create();
A.prototype = {
initialize: function() {
//public instance members
this.show = function() {
alert(I am A);
};
}
}
var B = Class.create();
Object.inherit(A, B);
Object.extend(B.prototype, {
initialize: function() {
//base class construction
this.base();
//override show
var oldShow = this.show.bind(this);
this.show = function() {
oldShow();
alert(I am EXTENDED A);
};
}
});
var test = new B();
B.show(); // alerts I am A and I am EXTENDED A
This technique comes right from by blog post on the inheritance model.
Now, if you're looking to tack (or override) methods on existing
instances... you don't need a special addPlugin() method like what you
started doing. You can just take advantage of plain old javascript...
(Assume we are back to using the definition of A from your original
post)...
var oldShow = A.show.bind(A);
A.show = function() {
oldShow();
alert(I am EXTENDED A);
};
Notice in my first example (the object oriented approach), and in this
example (the static object version) I use a .bind() call. Doing so
ensures
that if A.show() ever tried to access this, it would still point to
the
correct scope.
For instance, imagine A.show() looked like this:
function() {
alert(this.name);
}
Ok... so I'll stop now I guess, just realize this list isn't really
supposed
to be a support list. :-)
Hope this has helped though.
--
Ryan Gahl
Application Development Consultant
Athena Group, Inc.
Inquire: 1-920-955-1457
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: adding $parent to Object.extend
You may find my blog entry from last week to be interesting here: http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html As I state in the entry, I borrow from Kevin Lindsey's inheritance model, but have made it work quite nicely with prototype, and honestly think it would fit nicely into the core (keep Object.extend as is but add Object.inherit) On 3/29/07, Mislav Marohnić [EMAIL PROTECTED] wrote: On 3/30/07, Lorderon [EMAIL PROTECTED] wrote: Many times there's a need to call the parent method from the extended class object. This can be done easily by adding the $parent to be used inside Object.extend() method. You're touching sensitive ground here. There are many OOP implementations in JavaScript: 2 or 3 are for Prototype (you can find them in Trac), there are several on various sites and blogs, but the most notable (IMO) is Dean Edwards' Base. We're aiming to bring support for something like Base in Prototype 2.0. I believe that we will begin experimenting starting from version 1.6, but I still need to check with Sam for find out if his intentions have maybe changed in the past few months. -- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: adding $parent to Object.extend
And the reason to keep Object.extend as is is that it comes in very handy for scenarios other than class level inheritance, where bulk property copying is desired (like for default options during object construction for instance) On 3/29/07, Ryan Gahl [EMAIL PROTECTED] wrote: You may find my blog entry from last week to be interesting here: http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html As I state in the entry, I borrow from Kevin Lindsey's inheritance model, but have made it work quite nicely with prototype, and honestly think it would fit nicely into the core (keep Object.extend as is but add Object.inherit) On 3/29/07, Mislav Marohnić [EMAIL PROTECTED] wrote: On 3/30/07, Lorderon [EMAIL PROTECTED] wrote: Many times there's a need to call the parent method from the extended class object. This can be done easily by adding the $parent to be used inside Object.extend() method. You're touching sensitive ground here. There are many OOP implementations in JavaScript: 2 or 3 are for Prototype (you can find them in Trac), there are several on various sites and blogs, but the most notable (IMO) is Dean Edwards' Base. We're aiming to bring support for something like Base in Prototype 2.0. I believe that we will begin experimenting starting from version 1.6, but I still need to check with Sam for find out if his intentions have maybe changed in the past few months. -- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.com -- Ryan Gahl Application Development Consultant Athena Group, Inc. Inquire: 1-920-955-1457 Blog: http://www.someElement.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: new Event functionality
Lastly, why don't I add this functionality separately instead of trying to get Prototype patched? It is because the Event class does it's own caching in such a way that cannot be extended, so such efforts would be duplicating the caching and over-complicating cleanup procedures. This is where I was taking issue before. You incur no real performance or memory hits by keeping an extra reference (if you wanted a local caching policy for a class, that is). 2 references to the same object do not more memory take. Sigh... we just disagree on what point this stuff needs to be added. I really think just a simple wrapper is fine, that the core is not the place to go throwing this in. If a wrapper just wasn't possible, I can see it. But, I'm not really passionate about my position. So this will my final spout about it :-) Good luck with the patch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: new Event functionality
So a couple of hours turned into all day. That's just my life these days. We
have a big demo we're getting ready for on Wed. (I can't wait until we can
release some of this stuff)
Anyway, I'll have to try again to write something more concrete for you
later in the week. Feel free to badger me for it.
Basic premise though (mind you this pure pseudo): (also, I'm thinking a
special EventGC is not even needed, just give the wrapper class a dispose
method and use the DisposableGC)
EventObserverWrapper = Class {
observers = [],
observe: function(element, eventName, handler, {any other params to make a
code complete wrap})
{
observers.push(
{
element: element,
eventName: eventName,
handler: handler
});
Event.observe(element, eventName, handler);
},
dispose: function()
{
$A(this.observers).each(function(observer)
{
Event.stopObserving(observer.element, observer.elementName, observer.handler
);
observer = null; //de-reference to remove chances of circular leaks
});
this.observers = null;
}
}
someClass = Class {
eventCache: new EventObserverWrapper(),
initialize: function(someElement)
{
eventCache.observe(someElemtent, click, function() { alert(clicked); }
);
doSomething();
this.arrayOfDraggablesAndAllKindsOfStuffWithDisposeMethods = [...objects
galore...just an example...];
},
dispose: function()
{
$A(this.arrayOfDraggablesAndAllKindsOfStuffWithDisposeMethods
).each(function(obj)
{
globalGC.add(obj);
}
this.arrayOfDraggablesAndAllKindsOfStuffWithDisposeMethods = null;
globalGC.add(this.eventCache);
this.eventCache = null;
}
}
...and even extend the DisposableGC a bit to handle auto queuing the
children items. The end result is a pile of objects in the GC, each disposed
every XXX milliseconds, leaving the user to continue interacting with the
application.
DisposableGC.cleanup = function(obj)
{
for (var p in obj)
{
if (typeof obj[p] == object obj[p].dispose typeof obj[p].dispose ==
function)
this.add(obj[p]);
}
if (obj.dispose typeof obj.dispose == function)
obj.dispose();
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: new Event functionality
Colin... since it has been a while since I've contributed anything novel
here, I'd like to offer up some critiques and some code to possibly help you
out on this path you're on (especially since you mention some performance
issues).
What you are specifically talking about (in this portion of this thread
anyway) is automated garbage collection. You have a great start, in that GC
is extremely helpful, however I feel that you are coupling the concept too
tightly with the Event system. In other words, design everything as
generically as possible and you'll be able to apply to many different
scenarios. Event wiring is one concern... garbage collection (of anything)
is another concern... separate them.
Also, consider a situation where your tooltip is in reality some sort of
application dialog (or wizard), with potentially many children widgets in
it, that all have N disposables, and maybe a table of data with 100+ rows
where each row has a click handler (etc.., point being some arbitrarily
complex object). Under your system, closing the tooltip would set off a boat
load of synchronous dispose calls, therefore preventing any further
application functions until all the teardown is complete, therefore not
making for an entirely scalable solution (evident in your performance
findings).
Below is my Garbage Collector base class, and a very basic specialized
subclass called DisposableGC. I use this system in my widget framework, and
it indeed makes it easier on the developer. Its asynchronous (obviously
js's asynch is merely interruption based) operation makes it a performance
booster as well... The same scenario described above no longer blocks the
UI.
(copyright addition because it is part of a system I will eventually be
distributing, at least in part, commercially... sorry about that)
/*
Copyright 2005-2006-2007 Ryan Gahl
This code is provided as-is without warranty. You may use and distribute it
freely as long as this copyright notice remains.
This license of use applies only to the below provided code. Future versions
of the same code may be released by Ryan Gahl
or another approved entity (company for which he is employed) for commercial
distribution.
This license does not apply to any such future derivations, although at such
time you may still continue to use this code.
*/
/**
* @namespace RWG
*/
var RWG = {};
/**
* @namespace RWG.GarbageCollection */
RWG.GarbageCollection = {};
/** @class RWG.GarbageCollection.GCBase */
RWG.GarbageCollection.GCBase = Class.create();
RWG.GarbageCollection.GCBase.prototype =
{
/*
* @Constructor
* @param {integer} frequency (optional)
initialize: function()
{
///
/// Private member variables (only visible to privileged methods of
this class)
///
var gcArray = [];
var collectionInProgress = false;
var manualCollectionInProgress = false;
var collectionFrequency = arguments.length 0 ? arguments[0] : 100;
///
/// Public privileged instance methods (have visibility to private
members and only available to instances)
///
/**
* Called in order to queue an object up for asynchronous garbage
collection (i.e. disposal)
* @method
* @memberOf {RWG.GarbageCollection.GCBase}
* @param {Object} object The object to add to the GC instance's
collection queue.
*/
this.add = function(object)
{
if (object)
{
object.inGarbageCollection = true;
gcArray.push(object);
if (!collectionInProgress)
this.collect(collectionFrequency);
}
};
/**
* Abstract method with no base implementation (must be overriden)
* @method
* @memberOf {RWG.GarbageCollection.GCBase}
*/
this.cleanup = function() { throw new Error(No implementation has
been provided for the RWG.GarbageCollection.GCBase.cleanup() method (must be
overriden from a subclass)); };
/**
* Tells the garbage collector to start collecting in intervals of
{frequency} milliseconds
* @method
* @memberOf {RWG.GarbageCollection.GCBase}
* @param {Milliseconds} frequency
*/
this.collect = function(frequency)
{
collectionFrequency = frequency;
if (!manualCollectionInProgress)
{
if (gcArray gcArray.length 0)
{
collectionInProgress = true;
this.cleanup(gcArray[0]);
gcArray.splice(0,1);
}
if (gcArray gcArray.length 0)
{
setTimeout(function()
{
this.collect(frequency);
}.bind(this), frequency);
}
else
collectionInProgress = false
