[Prototype-core] Re: 1.6.0.3 release?
Nope, I read it. Just because the release date for 1.6.0.3 was 16 April and it's now August doesn't mean that Prototype has stagnated. For at least half the planet, it's summer time. People do things like vacation. I know Tobie is/was busy hacking on Prototype to make it work with Caja. And if you've been following the discussions here recently, I think the team has been thrashing out some very pressing issues. I'm not even a huge proponent of Prototype, but it really feels like you're just looking for an excuse to try another framework. And to that end, I'm rising to the bait... so I won't any more. On 18 Aug, 2008, at 1:32 PM, Johan McCain wrote: Jeff, I guess you didn't read my entire mail. It's based on Lighthouse showing 1.6.0.3 being expected on Apr 16th. That's 4 months ago. Regards, Johan On 18 aug, 22:28, Jeff Watkins [EMAIL PROTECTED] wrote: Dude, I don't know what planet you're living on, but where I live 15 Aug was Friday and today is Monday. Judging the activity of an ENTIRE project by the mailing list activity over the weekend is simply silly. On 18 Aug, 2008, at 1:18 PM, Johan McCain wrote: Ah well, core is not as active as it once was. Lighthouse shows Expected: Apr 16th Since we can't afford to wait we'll be looking into some other frameworks with more activity. Thanks anyway, Johan On 15 aug, 15:39, Johan McCain [EMAIL PROTECTED] wrote: Hi, Are there any plans to release 1.6.0.3? Just checking since the deadline on Lighthouse says 'Late' while the outstanding issues have had a patch attached for some time. We would love to get our sites working again on newer versions of Opera and Safari. Thanks and God Bless, Johan --~--~-~--~~~---~--~~ 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: Status of property 'name' within Class.create(d) functions
Off the top of my head, I'd guess you're using FireFox. I know the JS
engine in FireFox (SpiderMonkey) exposes the name of a function via
the `name` property, however, I don't know whether that property is
mutable.
My guess, from the behaviour of your code, is `name` is not a mutable
property.
On 8 Jun, 2008, at 9:06 PM, Franck PORCHER wrote:
Hello,
I have been trying for days o understand what I have missed.
I have narrowed down the problem to this, where I create a simple
class 'foo' that I extend to assign a private member 'name' set to
'FOO':
var foo = Class.create({});
Object.extend( foo, { name : 'FOO' } );
Then :
alert(foo.name)
surprisingly displays
klass
(instead of FOO)
Samething if I explicitely force the value to 'FOO'
foo.name = 'FOO'
Is there someone in the position to tell me what is going on, and
why foo's private member 'name' does not hold its value. This does
not happen if I choose another name for the private member.
This has been most upsetting to me for days now, and I fail to
understand what I am missing.
So thank you to anyone who would help me understand my mistake if
this is not a bug.
Franck PORCHER
--~--~-~--~~~---~--~~
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: Timeline for supporting native array methods?
Tobie, thanks or the response. I'd figured these were both well known issues, so I didn't even bother to check the bug database. I'll file both shortly since they're busting demos of our new library when running against Prototype (instead of Dojo). On 17 Apr, 2008, at 12:12 AM, Tobie Langel wrote: Hi Jeff, Sorry for the late response, we're in the middle of a triple move here: Changing versioning system (svn to git), bug report system (Trac to Lighthouse), and documentation system (external to inline)... Both these issues would be better adressed with relevant bug reports. Best place to do so is in our bug tracking system system: http://prototype.lighthouseapp.com/ Thanks for your help, Tobie --~--~-~--~~~---~--~~ 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] Timeline for supporting native array methods?
Is there any timeline for when Prototype will cease replacing the native implementations of map, filter, etc? I had thought this change was part of 1.6, but unless I'm misreading the source, 1.6.0.2 still overwrites the native implementations. Additionally, has anyone looked at why prototype's Array#map method doesn't work on NodeLists returned from Safari's querySelectorAll method? --~--~-~--~~~---~--~~ 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: Enumerable Map() oddity.
On 4 Dec, 2007, at 8:23 AM, John-David Dalton wrote:
The map method is passing 2 params to the iterator.
This makes the Element.next() go nuts cause its second param is used
for sibling offset.
In PHP array_map only passes the value and not the index.
It makes since for Enumerable.each() to send both, but I think map
should be left to just the value. I image there are more cases where
this sort or error would occur.
I believe this is a result of trying to make each and map adhere more
closely to the JavaScript 1.6 enumeration methods for Arrays which
pass 3 arguments: the value, the index, and the original array.
This is a case were you'll just need an adapter method. Silly as it
seems, this will work fine:
function(element){ return Element.next(element); }
This issue highlights an instance where better documenting the
prototype of the iterator function would help (as recently mentioned
in an email to this list). If the documentation clearly stated that
the iterator function should accept 3 arguments, you wouldn't have
tried to use Element.next as an iterator without an adapter.
--
Jeff Watkins
ui wrangler
online apple store
The online store is looking for a JavaScript superstar with a strong
software engineering background. Is that you? Drop me an email if
you're interested.
--~--~-~--~~~---~--~~
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: Hiding a not-yet-rendered DOM node
Ignacio Coloma wrote: Hi, I know that prototype should be kept as simple as possible but this is a common use case IMHO. This is a technique to avoid the brief flash that happens when you want a DOM node hidden if the browser has javascript, but be shown if it does not: ... Why not use noscript? What are the use cases? noscript is kind of the reverse of what he's talking about. In noscript you get the element only when scripting is not enabled. In his example, you ALWAYS get the element, but when scripting is enabled, it is hidden. This is a pretty common technique. So common, I usually have a CSS class specifically for it: .hideWhenScripting. The easiest example to understand would be: input type=text onkeyup=liveSearchinput type=submit class=hideWhenScripting value=Search Of course, the onkeyup attribute is bogus, but you get the idea. The input performs live search when JavaScript is enabled and the submit button is hidden, but when JavaScript is disabled, we want to display the Search button to search on the server. -- Jeff Watkins ui wrangler online apple store The online store is looking for a JavaScript superstar with a strong software engineering background. Is that you? Drop me an email if you're interested. --~--~-~--~~~---~--~~ 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: Any reasons for not including String#size ?
Er, sorry, the smart-ass in me got the best of me.
I think Prototype is in danger of starting to bloat like other
libraries and I think requests like this are exactly why.
There's no possible reason to have a size method when there's a
perfectly good length property.
I'm certain someone will argue that Ruby strings have size methods.
And of course, they might be right. But that's not a compelling
reason to add a size method to JavaScript strings. Prototype is
already a large enough download without adding unnecessary features.
On Sep 29, 2007, at 4:55 PM, Jeff Watkins wrote:
Maybe you've heard of the length property on String?
Why on earth would you need a size method?
On Sep 29, 2007, at 8:45 AM, Sylvain ZIMMER wrote:
Hi all,
I was a bit surprised not to find a size() method on String (like
Array, Enumerable, Hash, ...)
So maybe there is a good reason not to (and I'd like to know it ;-),
but wouldn't it be nice to have
String.prototype.size = function() {
return this.length;
}
so that we can call size() whatever the object type is?
thanks!
--~--~-~--~~~---~--~~
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: Any reasons for not including String#size ?
A lot of 50 byte features and you have enormous files.
On Sep 29, 2007, at 6:08 PM, Sylvain ZIMMER wrote:
Well I was validating data elements and I just had to do something
like :
if ((typeof data)==string) size=data.length else size=data.size()
which seems quite counter-intuitive, maybe violating the
http://en.wikipedia.org/wiki/Principle_of_least_surprise
I don't take the prototypejs.org filesize as a valid argument for not
including String#size since it's less than 50bytes. Valid arguments
(to me) would include performance, API consistency, ... ?
On Sep 30, 2:20 am, Jeff Watkins [EMAIL PROTECTED] wrote:
Er, sorry, the smart-ass in me got the best of me.
I think Prototype is in danger of starting to bloat like other
libraries and I think requests like this are exactly why.
There's no possible reason to have a size method when there's a
perfectly good length property.
I'm certain someone will argue that Ruby strings have size methods.
And of course, they might be right. But that's not a compelling
reason to add a size method to JavaScript strings. Prototype is
already a large enough download without adding unnecessary
features.
On Sep 29, 2007, at 4:55 PM, Jeff Watkins wrote:
Maybe you've heard of the length property on String?
Why on earth would you need a size method?
On Sep 29, 2007, at 8:45 AM, Sylvain ZIMMER wrote:
Hi all,
I was a bit surprised not to find a size() method on String (like
Array, Enumerable, Hash, ...)
So maybe there is a good reason not to (and I'd like to know
it ;-),
but wouldn't it be nice to have
String.prototype.size = function() {
return this.length;
}
so that we can call size() whatever the object type is?
thanks!
--~--~-~--~~~---~--~~
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
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
});
--~--~-~--~~~---~--~~
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: Indiscriminate use of breaking into words function $w()
Ultimately, this and several other topics come down to the fact that Prototype is the JavaScript library for Ruby programmers. This isn't bad, it's just something that non-Ruby coders like myself have to come to grips with. Prototype prefers method names like uniq rather than unique, for no other reason than its Ruby heritage. Similarly, constructs like $w which serve no purpose other than as a syntactic sugar sprinkled on top make the Ruby programmers feel at home - even if they do make the rest of us feel out of place. On Sep 5, 2007, at 6:48 AM, Thomas Fuchs [EMAIL PROTECTED] wrote: for the $w() thing: you _could_ build a preprocessor for your personal prototype copy that does a $w() - [] conversion upfront; but as stated earlier in the thread, there's absolutely nothing to gain from this, performance-wise. best, thomas --~--~-~--~~~---~--~~ 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: Indiscriminate use of breaking into words function $w()
On Sep 5, 2007, at 7:28 AM, Thomas Fuchs wrote:
Am 05.09.2007 um 16:22 schrieb jdalton:
I did not know that using brackets is slower.
No, that's just a claim. :)
I'd welcome benchmarks for this (i've the feeling it's not really
measurable, but you never know...).
Thomas, brackets once parsed have no impact on code execution speed.
The following code:
for (var i=0; i1; ++i) {
if (...some test...)
...do something...
}
has the same execution profile as:
for (var i=0; i1; ++i) {
if (...some test...) {
...do something...
}
}
Because the extra time (on the order of tiny fractions of a
millisecond) is spent when parsing the JS rather than executing it.
On the other hand, $w is an execution-time construct and its impact
can be measured.
Both come down to a style issue, do you like {} around one line
statements (I don't) and do you like to mimic the syntax/features of
another language rather than JavaScript (I don't).
--~--~-~--~~~---~--~~
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: iterable/$A
Not only that, but if the array contains objects, the toString()
method on the Object prototype will cause all but one object to be
removed from the array, because all objects without an overridden
toString() method report [object].
On Aug 30, 2007, at 5:50 PM, Tom Gregory wrote:
On Aug 30, 2007, at 5:52 PM, Mislav Marohnić wrote:
On 8/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
also, for generating unique arrays:
function uniqueArray( array ){
var uniqueHash = {}, unique=[], i;
for( i=array.length; i--; ){
if( !uniqueHash[ a[i] ]){
unique.push( array[i] );
uniqueHash[ a[i] ] = true;
}
}
return unique;
}
Although I expect this to be faster (linear time), this produces
incorrect results for certain arrays due to the implicit toString
(). Arrays of DOM elements might not be properly uniq-ed, for
example. The same is true for the following array (which uniq()
handles properly):
var a = [true, true];
console.log( a.uniq() );
// [true, true]
console.log( uniqueArray(a) );
// [true]
TAG
--~--~-~--~~~---~--~~
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: $('my-element').$$('a[href=foo]');
How about changing the name from Element.select to
Element.selectElement and Element.selectAllElements? This would be in
keeping with the future DOM methods - which prototype could adopt when
supported.
On Aug 29, 2007, at 2:17 PM, Jacob Rockowitz [EMAIL PROTECTED]
wrote:
There is a 'select' method already used form inputs but I guess it is
okay to have two DOM methods with the same method name doing
completely different things.
http://www.w3schools.com/htmldom/met_text_select.asp
At same time, I could see someone building an HTML editor using
prototype.js or a just browser wanting to add a 'select' method to the
DOM that was similar to the input.select(), it would select the
innerHTML of an element.
~ jake
On Aug 29, 4:47 pm, Nicol�s Sanguinetti [EMAIL PROTECTED] wrote:
On 1.6.0 this has been aliased to select
$(my-element).select(a[href=foo])
-Nicolas
On 8/29/07, Jacob Rockowitz [EMAIL PROTECTED] wrote:
Hi,
I have been using Element#getElementsBySelector a lot and keep
feeling
that the method's name is too verbose, couldn't it just be an
Element#$
$.
ex:
instead of
$('my-element').getElementsBySelector('a[href=foo]');
it could be
$('my-element').$$('a[href=foo]');
I understand that the usage of the $ is for utility functions but
this
seems like a reasonable idea.
http://dev.rubyonrails.org/ticket/9424
thanks
~jake
--~--~-~--~~~---~--~~
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: $('my-element').$$('a[href=foo]');
Oh come on. The syntax of this stuff is getting pretty opaque. It's bad enough with libraries like jQuery which seems to delight in redefining nearly every DOM call - I tried reading some code that used jQuery recently and it made absolutely no sense. Would it kill us to have method names that are self-documenting? On Aug 29, 2007, at 2:57 PM, Ih�rosi Wiktor [EMAIL PROTECTED] wrote: This is why I suggested that we use the Selectors API (selectAllElements) instead of select. Chaining with $$ in the middle is just too much. imho it's not too much. I agree with Jake, it would be a logical step if we use $$ for selectors. --~--~-~--~~~---~--~~ 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: Array inline filtering.
Richard, this seems similar to the standard js 1.6
Array.prototype.filter method. You might be well advised to look at
the Mozilla MDC site for example code that does this.
On Aug 23, 2007, at 2:32 AM, Richard Quadling
[EMAIL PROTECTED] wrote:
Hi.
I've just created a small function to filter an array. Sort of the
reverse of each+without.
/*
Version 1.0.0 - Thursday, 23 August 2007 10:25 am
*/
Object.extend (
Array.prototype, {
/***/
/* Allow inline filtering of an array. */
/***/
filter: function(f_Filter) {
var a_Return = [];
for (var i = 0, length = this.length; i length; ++i)
if (f_Filter(this[i]))
a_Return.push(this[i]);
return a_Return;
}
}
);
Usage :
a_Array.filter(function(item){return true/false;}).chain().chain();
With that 2 questions.
1 - Have I made any REALLY obvious mistakes.
2 - How do I submit this to the core?
Richard
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--~--~-~--~~~---~--~~
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: Enumerable.pluck()-like setter
I would definitely second the nomination of a name that actually
means something, like 'setAttribute' or similar. But then I'm a fan
of self documenting function names - even when they're long and
include all the letters in words.
On Aug 15, 2007, at 8:58 AM, Ken Snyder wrote:
Tom Gregory wrote:
...
apply: function(iterator, attribute, value) {
return this.map(function(item, index) {
item[attribute] = value;
});
},
...
I've run into a need for this as well. I'd vote for including it
under
a name 'setAll' or 'setEach'.
Or, what is the exact opposite of pluck? Pin? Place? Affix? :P
- Ken Snyder
--~--~-~--~~~---~--~~
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: Unique Arrays
Except that many users of Prototype don't use Ruby. On Aug 4, 2007, at 5:55 PM, Mislav Marohnić [EMAIL PROTECTED] wrote: On 8/1/07, Ken Snyder [EMAIL PROTECTED] wrote: Unique might be specified array method in JavaScript 2.0--otherwise, yes, unique is more intuitive than uniq. uniq is Ruby. IMO, there's no need to alias unique to it --~--~-~--~~~---~--~~ 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
On Jul 18, 2007, at 10:08 PM, Ken Snyder wrote:
Object.assignGuid = function(object, prefix) {
if (prefix === undefined) prefix = '__guid';
if (!object.id) {
object.id = prefix + (arguments.callee.nextId++);
}
return object.id;
};
Object.assignGuid.nextId = 0;
I like your version (although, I'd echo the argument that Guid isn't
appropriate because we're not generating _globally_ unique IDs),
however, a slight tweak:
Object.assignId= function(obj, prefix) {
if (obj.id)
return obj.id;
return obj.id= (prefix||uniqueid_ +
arguments.callee._nextId++;
}
Object.assignId._nextId= 0;
Then we could add:
Element.Methods.assignId = Object.assignId;
So we have both a generic ID assigning method _and_ we have a method
on extended elements to assign an ID.
--~--~-~--~~~---~--~~
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] suggestion: Object.applyDefaults
This is similar to Object.extend, but you get back the original
object and keys aren't overwritten:
Object.applyDefaults = function(obj, defaults) {
obj= obj||{};
if (!defaults)
return obj;
for (var p in defaults) {
if (p in obj)
continue;
obj[p]= defaults[p];
}
return obj;
}
I use this all the time to accept a config hash and fill in default
values. This allows me to define my code a bit more modularly:
function MyClass(config) {
this.config= Object.applyDefaults(config, arguments.callee.DEFAULTS);
}
MyClass.DEFAULTS = {
...
};
I know the prototype way is to use Object.extend, but this allows a
greater modularity of code. For example, I can use the same defaults
multiple times.
--
Jeff Watkins
UI Engineer, Online Apple Store
--~--~-~--~~~---~--~~
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] Code formatting
Does anyone know why the majority of code seems to get mangled like
the first block?
My guess is that Google is trying to be clever...
On Jul 19, 2007, at 10:43 AM, Jeff Watkins wrote:
This is similar to Object.extend, but you get back the original
object and keys aren't overwritten:
Object.applyDefaults = function(obj, defaults) {
obj= obj||{};
if (!defaults)
return obj;
for (var p in defaults) {
if (p in obj)
continue;
obj[p]= defaults[p];
}
return obj;
}
I use this all the time to accept a config hash and fill in default
values. This allows me to define my code a bit more modularly:
function MyClass(config) {
this.config= Object.applyDefaults(config, arguments.callee.DEFAULTS);
}
MyClass.DEFAULTS = {
...
};
I know the prototype way is to use Object.extend, but this allows a
greater modularity of code. For example, I can use the same
defaults multiple times.
--
Jeff Watkins
UI Engineer, Online Apple Store
--~--~-~--~~~---~--~~
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] A Lightweight Set
I've often found myself using an object literal as a Set and after wishing I had some real Set operators, I finally found the time to write them. http://pastie.textmate.org/80530 I don't know whether this is core-worthy, but it might be helpful for someone else out there. Just a note, all methods are implemented as statics on the Set _class_ because I didn't want to pollute the contents of the set. The only current limitation is you can't reliably store keys which already exist in the Object prototype. Of course, I could add a wrapper object and prefix all the keys to get around this limitation, but the whole goal of this Set implementation was speed. So extra method calls aren't desirable. -- Jeff Watkins UI Engineer, online Apple store --~--~-~--~~~---~--~~ 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: A Lightweight Set
Wouldn't those methods be a better fit for the Enumerables or Hash ? Both Hash and Enumerable add numerous keys to the set. Or said another way, I can't store keys, values, map, find, etc in a Hash (unless I'm missing something clever). --~--~-~--~~~---~--~~ 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
Ryan, that's a great idea. Although I don't anticipate using it often, I can easily see how this would be indispensable in some circumstances. On Jul 17, 2007, at 6:32 AM, Ryan Gahl wrote: 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: Inheritance: your thoughts?
Alex, I like the class definition function method with the exception of returning a hash. It seems like it ought to be one way or the other. But then, I've never had any problem just going long-hand with my class definitions. One small quibble, I think it might be a little more clear were the class explicitly passed to the closure rather than using this. For most people, this is synonymous with an instance. On Jul 10, 2007, at 8:44 PM, Alex Arnell wrote: Patch URL (apply against latest inheritance branch revision): http://dev.rubyonrails.org/attachment/ticket/5459/block-notation.diff This patch lets a user optionally define a class inside a closure instead of a methods hash. Class definition inside a closure allows for some really interesting code, some of which I've outlined in a usage patterns pastie to save on message length. Usage Pastie URL: http://pastie.textmate.org/77884 --~--~-~--~~~---~--~~ 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 and JavaScript 1.6 Array methods
Fantastic. I know breaking backward compatibility is never a good thing, but I'm glad to hear that standards compliance is considered just as important. On Jul 10, 2007, at 3:38 AM, Mislav Marohnić wrote: On 7/10/07, Tobie Langel [EMAIL PROTECTED] wrote: Your post just triggered a commit (http://dev.rubyonrails.org/ changeset/7170). Check SVN for the latest implementation. Jeff, keep in mind that even this latest change still clobbers some native methods. This is because the native ones don't support $break, while ours do. It is never in our intention to overwrite native stuff, so I'll work on this more, trying to get it resolved. --~--~-~--~~~---~--~~ 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] Prototype and JavaScript 1.6 Array methods
Howdy, I'm investigating switching the online Apple Store from dojo to prototype (we're going to have to make big changes anyway if we're to track dojo's development from 0.4 to 0.9), however we've been making extensive use of the JavaScript 1.6 methods on Array (indexOf, map, forEach). I noticed in my initial testing that prototype (v1.5.1.1) stomps on the browser native versions of these methods. This doesn't seem like an ideal situation, as browsers are implementing these methods in compiled code. So the native version seems like it would be considerably faster. There's an open ticket for changes to make prototype compatible with JavaScript 1.6 (http://dev.rubyonrails.org/ticket/6650), any word on when this will be appearing in a release? -jeff --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
