From: Jorge on
> On Jan 4, 2:16 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> > On Jan 3, 8:11 pm, Jorge <jo...(a)jorgechamorro.com> wrote:
>
> > Safari 2.0.4 does have .hasOwnProperty()...
>
> That's as maybe.  Now check 2.0.3, then 2.02...

http://dev.rubyonrails.org/ticket/9700
(Both have it too)
--
Jorge.
From: Thomas 'PointedEars' Lahn on
JR wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Jorge wrote:
>> > JR wrote:
>> >> Jorge wrote:
>> >> > JR wrote:
>> >> >> No, it isn't, even in case you know exactly what you're doing.
>>
>> >> > Dear God ! Another step towards the abyss ?
>>
>> >> The guy asked our opinion. Mine was stated: I'm against type
>> >> augmentation although I know it's possible and can increase
>> >> expressiveness of JS. That's just an opinion and I can't see
>> >> how being prudent would be a step towards the abyss?
>>
>> Because your opinion expressed above is not based on prudence but on
>> irrational fear instead. It goes without saying that if one knows
>> exactly what they are doing, they must also be aware of the side
>> effects.
>
> No, it's prudence against the many that *think* they know what they're
> doing.

That is a non sequitur. Why support incompetence?

>> On a second thought, one might also want to program
>> non-interoperabilities out of the trim() implementation which is a goal
>> worth pursuing despite the reduced efficiency of the user-defined code.
>>
>> >> and "If something can go wrong, it will."
>>
>> Fear is a bad advisor.
>
> The cemetery is full of fearless men.

False analogy.

>> > That user defined properties -inherited or not- are enumerable isn't
>> > something to be afraid of,
>>
>> But to be kept in mind.
>>
>> > and String.prototype.trim() is a good example of handiness that can't
>> > break anything.
>>
>> That is, if it is done properly, contrary to the example. For it is
>> rather unlikely that anyone would plainly for-in iterate over String
>> instances or values without general property detection or side-effects
>> in mind.
>>
>> > If it broke a certain script, the culprit would be that script's
>> > author's ignorance, but instead you and Mark are mistakenly pointing
>> > at a nice feature of the language as the culprit and advocating to
>> > mutilate it... ¿?
>>
>> ACK
>
> No, you are mistaken.

I am not.

> Read again: I did not advise anyone to 'mutilate' JS, instead I commented
> (as an opinion, of course) to not use the 'augmenting-types' capability,
> given the context mentioned earlier in the same post [Douglas Crockford's
> note about the need of being careful when there are other scripts in the
> page].

In this very example augmenting the prototype object can do no harm at all
except to those who are stupid enough to for-in over String instances or
values without considering enumerable properties. Your categorical "do not
use" principle is in effect shifting the responsibility entirely from the
library user to the library author. Have you not seen enough inefficient
jQuery nonsense to see that this is a flawed concept?

> "Not to use something" is totally different from "mutilating something".

I was not referring to that part or to your statements in particular there.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Scott Sauyet on
On Jan 3, 7:18 pm, JR <groups_j...(a)yahoo.com.br> wrote:
> I've read the book too, but in my version (2008 in Portuguese) that
> function is slightly different, with one very important feature test:

My English copy of the book (2008, first edition) lists the OP's
version of the code, and then later in the same section lists the one
you supply, introduced by "The prototypes of the basic types are
public structures, so care must be taken when mixing libraries. One
defensive technique is to add a method only if the method is known to
be missing."


> Function.prototype.method = function (name, func) {
> if (!this.prototype[name]) {
> this.prototype[name] = func;
> }
> };

Clearly this is an improvement on the original. I agree with whoever
mentioned that this should have a verb, "setMethod", "addMethod", or
some such.

I don't much like modifying the prototypes of the built-in objects,
although I understand that it can be useful and powerful to do so in
at least some circumstances. But Crockford's only justification for
this is only that "[W]e no longer have to type the name of the
prototype property. That bit of ugliness can now be hidden." His
original version (as supplied by the OP) seems to have no advantage.
I certainly don't see that this:

Number.method('integer', function () {
return Math[this < 0 : 'ceil' : 'floor'](this);
});

is any less ugly than this:

Number.prototype.integer = function () {
return Math[this < 0 : 'ceil' : 'floor'](this);
};

But when you add in the error checking, it is clearly less ugly than
this:

if (!Number.prototype.integer) {
Number.prototype.integer = function () {
return Math[this < 0 : 'ceil' : 'floor'](this);
};
}

So I think a version of this technique would be useful if you do
choose to enhance these prototypes.

-- Scott
From: JR on
On 4 jan, 15:03, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> On Jan 3, 7:18 pm, JR <groups_j...(a)yahoo.com.br> wrote:
>
> > I've read the book too, but in my version (2008 in Portuguese) that
> > function is slightly different, with one very important feature test:
>
> My English copy of the book (2008, first edition) lists the OP's
> version of the code, and then later in the same section lists the one
> you supply, introduced by "The prototypes of the basic types are
> public structures, so care must be taken when mixing libraries.  One
> defensive technique is to add a method only if the method is known to
> be missing."
>
> >    Function.prototype.method = function (name, func) {
> >        if (!this.prototype[name]) {
> >            this.prototype[name] = func;
> >        }
> >    };
>
> Clearly this is an improvement on the original.  I agree with whoever
> mentioned that this should have a verb, "setMethod", "addMethod", or
> some such.
>
> I don't much like modifying the prototypes of the built-in objects,
> although I understand that it can be useful and powerful to do so in
> at least some circumstances.  But Crockford's only justification for
> this is only that "[W]e no longer have to type the name of the
> prototype property.  That bit of ugliness can now be hidden."  His
> original version (as supplied by the OP) seems to have no advantage.
> I certainly don't see that this:
>
>     Number.method('integer', function () {
>         return Math[this < 0 : 'ceil' : 'floor'](this);
>     });
>
> is any less ugly than this:
>
>     Number.prototype.integer = function () {
>         return Math[this < 0 : 'ceil' : 'floor'](this);
>     };
>
> But when you add in the error checking, it is clearly less ugly than
> this:
>
>     if (!Number.prototype.integer) {
>         Number.prototype.integer = function () {
>             return Math[this < 0 : 'ceil' : 'floor'](this);
>         };
>     }
>
> So I think a version of this technique would be useful if you do
> choose to enhance these prototypes.
>
>   -- Scott

Brilliant! ITA.

Cheers,
JR
From: Garrett Smith on
Eric Bednarz wrote:
> David Mark <dmark.cinsoft(a)gmail.com> writes:
>
>> On Jan 3, 1:50 pm, Jorge <jo...(a)jorgechamorro.com> wrote:
>
>>> authors know about .hasOwnProperty() existence and purpose ?
>> You truly are a student of Crockford. For about the millionth time,
>> that method doesn't work in "ancient" browsers like Safari 2.
>
> It works in Safari 2.04; I would expect that people who are stuck with
> OS X 10.4 would still run system updates.
>

Ah but 10.4 can get Safari 3 and 4. 10.3 users are a different matter.

Now for 10.3, you'd need to support Safari 1. I do know any way to test
Safari 1 on 10.4.

Apple bundles the Browser with the operating system, but somehow does
not suffer the legal troubles that Microsoft has experienced in doing
the same. Apple does a lot worse things and gets away with those, too.

Apple a good example what is wrong with business in America.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/