Jake Verbaten wrote:
> Scott Sauyet wrote:
>> Jake Verbaten wrote:
>> I don't want to have to wade my way through code to find that one
>> developer saw another's use of `Object.create`, looked it up in the
>> specs, saw the great features that would allow them to add, say, a non-
>> enumerable property, incorporated that in the project, found it worked
>> fine in their quick tests, even noted in the console that the property
>> was not enumerated, and declared themselves done, because it will be
>> weeks or months later that I'm coming in with an odd use case that
>> exposes a bug, only in IE<9, because that property was in fact
>> enumerable.
>
> What your describing is a) a bad developer and b) how your team failed to
> use code reviews, c) how your team failed to have unit tests.
I didn't say this had happened. But this is the sort of thing I have
seen on larger teams, even where most of the developers are competent,
the team either pairs or does other forms of code review, and the code
has an excellent set of unit tests. When some of these conditions
fail, it's even more likely.
>> That's why when working with larger teams, I try to use shims only
>> when they can completely do the job of replacing that which they shim.
>
> Meh on a large project that uses javascript you before hand choose to either
> use ES3 or ES5. Then every developer sits down and realises the limitations
> of the cross browser shim that is ES5-shim. Of course I dont see why you
> would choose ES3.
>
> The same with your DOM-shim / abstraction of choice.
Have you ever worked on a large team? Especially one with more than
twenty developers? We have more than twenty people in our UI code,
and many more doing our (non-JS) back end.
When I joined my current project, there were already six or eight
developers working on the JS, and probably not one of them had ever
heard of ECMAScript. Since then, I've been able to hire more
experienced and more competent developers. But many of those original
ones are still around, and they've become fairly adept at JS. We have
some team members who are heavy-hitters, and they get the more
challenging assignments.
We probably have four or five different types of inheritance schemes
going on in the application now, although we're slowly reducing that
set. My examples using Object.create was not an actual problem we
faced, since we don't use Object.create. Those of us who know it's
available have not looked to introduce the shims, because we haven't
found the need. But it is the type of problem I can easily imagine
facing.
I'm still curious if you have a response to this:
>>> If you take a look at my pd project you see I really dislike handling
>>> `new <Function>` or constructor functions by hand.
>
>> Why do you object? I've never shared this distaste.
>> var Shape = function() { /*...*/}
>> var Circle = function() {/*...*/}
>> myNamespace.inherit(Shape, Circle);
> [ ... ]
>> Do you also find this pattern inelegant?
>
> Yes,
>
> var Shape = { ... };
> var Circle = Object.make(Shape, {
> ...
> });
And presumably Shape and Circle serve as prototypes and pseudo-classes
for shapes and circles? While I understand this style, I've never
seen any particular reason to prefer it to what's been the standard JS
mechanism for a long time. It's not that I object. But this seems,
as you say, just a matter of style. You earlier seemed to be arguing
that others are doing it wrong, not that you simply prefer a different
style. Have I been reading your posts wrong?
> However my object is a matter of style. I really like prototypes as
> classes<http://www.2ality.com/2011/06/prototypes-as-classes.html>
>
> I also prefer to treat `.constructor` as the constructor function and not
> some other one.
It's clear that you do prefer it. Can you present any cogent
arguments as to why others should also prefer it?
-- Scott
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
