On Thu, Jul 3, 2008 at 10:28 PM, Ryan Gahl <[EMAIL PROTECTED]> wrote:
> Why are you calling
>> shared instance members (where member is property/method) "static"?
>
>
> Sorry, that's not what I meant to say. If you read my blog post (
> http://www.someelement.com/2007/03/multiple-inheritance-with-
>
> Why are you calling
> shared instance members (where member is property/method) "static"?
Sorry, that's not what I meant to say. If you read my blog post (
http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html)
- I explain what I mean by "prototype-static".
Ok, let's
On Jul 3, 10:34 am, "Ryan Gahl" <[EMAIL PROTECTED]> wrote:
> Javascript does not have classes, true. Javascript does have instance
> variables, and does have static members (where in the world are you getting
> this stuff). You're kind of saying "javascript is not object oriented",
> which it i
>
> Kangax's point might be moot for simple constructors, but that doesn't
> make it "plain wrong". Suppose you have a constructor with 100
> methods and you want 100 instances, is it better to define each and
> every method on each and every instance, or put them on the
> constuctor's prototype?
On Jul 3, 4:09 pm, "Ryan Gahl" <[EMAIL PROTECTED]> wrote:
> > Constantly repeating how I'm "plain wrong" and
> > making up assumptions about my reasonings, my experience and skills is
> > not something I would expect of you.
>
> You are saying things about a pattern that are wrong, and there's n
>
> Constantly repeating how I'm "plain wrong" and
> making up assumptions about my reasonings, my experience and skills is
> not something I would expect of you.
You are saying things about a pattern that are wrong, and there's no other
kind of wrong other than plain :). The only thing I said th
Ryan, no need to get offensive about patterns that work for you (and
your team).
I am certainly not throwing pointless arguments about some
hypothetical performance issues. Everything I said comes from
experience in applications I have worked on. It also comes from people
who worked on JS applicat
>
> It's gotten a bit testy, but I just wanted to say that I, for one,
> have appreciated the discussion thus far ;-)
Sorry about the feistiness, but glad someone is finding it valuable.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
Just re-read my last post - kangax, sorry for getting all "DUDE!!" on you...
I'll try to keep my tone down if we continue the exchange :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" group
Seriously, stop with the performance stuff - it's not an issue. You keep
bringing it up and I'm here to tell you it's just plain wrong. And my
example is a perfect example of the benefit of the assignment of instance
members within the constructor as rule. In fact, in this example, it's the
ONLY wa
I'm not sure what this has to do with anything.
If a person doesn't know what Class.create does with an object (passed
to it), it's their problem ; )
Bending language (and clogging performance) to meet inept programmers
expectations doesn't seem like a wise thing to do.
Adapting a "private members
It's gotten a bit testy, but I just wanted to say that I, for one,
have appreciated the discussion thus far ;-)
:Dan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" group.
To post to this g
One more little illustration:
var blah = Class.create({
someArray: [],
initialize: function() {}
});
var foo1 = new blah();
var foo2 = new blah();
foo1.someArray.push("blahblah");
alert(foo2.someArray.length); //alerts 1, most people new to js will expect
0
How many times has this issue been pos
>
> I would appreciate if my reasonings weren't claimed to
> be "FUD" : )
I said "borderline FUD" :)
And ok. It's not FUD. It's just not correct.
But once again I disagree with both statements, where you say private
members destroy any features of javascript. In fact, they are implemented by
On Jul 2, 3:36 pm, "Ryan Gahl" <[EMAIL PROTECTED]> wrote:
> > It's obviously a matter of priorities. For me, performance is usually
> > one of the key factors. Simulating "private" properties (in a highly
> > dynamic language) does not compensate for the decreased speed.
>
> But, there is no dec
>
> It's obviously a matter of priorities. For me, performance is usually
> one of the key factors. Simulating "private" properties (in a highly
> dynamic language) does not compensate for the decreased speed.
But, there is no decreased speed noticeable, is what I'm saying. So you're
sacrificing
On Jul 2, 1:12 pm, "Ryan Gahl" <[EMAIL PROTECTED]> wrote:
> Of course there are. To say otherwise is confusing.
I'm not sure I understand what you mean, Ryan.
JavaScript doesn't have a notion of "static" (except for a reserved
keyword that's not even implemented). There are "direct" members an
>
> There are no "static" or "instance" methods on js objects really : )
> I understand what you mean, but it just sounds confusing.
Of course there are. To say otherwise is confusing.
You could do that, though "fat" constructors is usually not a good
> idea. It would also cripple performance if
Hi,
On Jul 2, 2008, at 18:36 , kangax wrote:
>> Prototype doesn't provide any special facility for defining "static"
> members (as majority defines it). All it takes is to declare them as
> members of "class" function.
>
> var Foo = Class.create({ ... })
> Foo.blah = 'my static property';
Yeah,
On Jul 2, 11:43 am, Antoine Quint <[EMAIL PROTECTED]> wrote:
> On Jul 2, 2008, at 17:27 , Ryan Gahl wrote:
>
> > Nowhere on that page does it say that static class methods are
> > copied to the prototype.
>
> I think there are only ever static class methods passed in
> Class.create(). When you d
On Jul 2, 2008, at 17:27 , Ryan Gahl wrote:
> Nowhere on that page does it say that static class methods are
> copied to the prototype.
I think there are only ever static class methods passed in
Class.create(). When you do this:
Class.create({
initialize: function() {
// some code h
Nowhere on that page does it say that static class methods are copied to the
prototype. If, for whatever reason, it actually IS supposed to work that
way, it's a major flaw, and should be fixed immediately. But like I said, it
wouldn't make any sense if it worked like that, and so it doesn't.
So,
On Jul 2, 2008, at 17:11 , Ryan Gahl wrote:
> Why would Class.create() copy static class members to the prototype?
> That doesn't make any sense. That completely rules out the
> possibility that the developer, you know, wanted them to remain
> static...
As far as I know, that's how Class.c
Why would Class.create() copy static class members to the prototype? That
doesn't make any sense. That completely rules out the possibility that the
developer, you know, wanted them to remain static...
On Wed, Jul 2, 2008 at 10:08 AM, Antoine Quint <[EMAIL PROTECTED]>
wrote:
>
> Hi Ryan,
>
>
Hi Ryan,
On Jul 2, 2008, at 17:01 , Ryan Gahl wrote:
> It probably has something to do with the fact that you are defining
> the getter/setter statically on the class itself, where in the
> second example, you are actually defining them at the instance
> level, which is what you want.
I d
It probably has something to do with the fact that you are defining the
getter/setter statically on the class itself, where in the second example,
you are actually defining them at the instance level, which is what you
want.
In your first example, I'll bet if you just do MyClass.test = "blah" it
w
Hi Darrin,
On Jul 2, 2008, at 16:28 , darrin wrote:
> Interesting, first time I've seen this. The alert is actually coming
> out of Class.create call. What about this
>
> var MyClass = Class.create({
> initialize: function() {
>this.__defineGetter__('test', function() {
> alert('in
Interesting, first time I've seen this. The alert is actually coming
out of Class.create call. What about this
var MyClass = Class.create({
initialize: function() {
this.__defineGetter__('test', function() {
alert('inside getter');
return 'foo';
});
this.__defineSet
28 matches
Mail list logo
