On Feb 17, 8:04 am, Scott Sauyet <[email protected]> wrote:
> Michael Haufe (TNO) wrote:
> > As you or the OP
> > or anyone else creates something beyond trivial code you mentally have
> > some notion of types and contracts in your mind.
>
> But the contracts I consider when programming in Java are very
> different from those I use when programming in COBOL, or when
> programming in LISP. When I program in Javascript, I don't usually
> think in terms of classes of objects, but in one-off objects that may
> or may not have certain properties. One of the great things about the
> language is the ability to add and remove arbitrary properties of
> objects.
And if you want scalable code you'll change what terms you consider
again. The "great things" about the language are also terrible things
when dealing with scale, hence the large number of meta-object
features introduced in ES5.
> >Its wiser to make
> > this explicit in your code using the features of the language than to
> > play a defensive programming game that is unnecessarily slow and
> > potentially verbose. There is no need for null/undefined checking on
> > the level being advertised here if the data structures were organized
> > in some manner instead of being thrown in some semblance of property/
> > method bags to interrogate on every use.
>
> You're right, if you're trying to code as though you were in a
> statically-typed language. JS certainly allows you to code in that
> manner. But IMHO that ignores the strengths of the language.
See above.
> > If by the definition of
> > dynamic people think it means its super 1337 cool and JavaScripty to
> > say:
>
> > (person2||{}).address||{}).zip || "no zip"
>
> > on every single member access, I think you are quite mistaken. Common
> > practice and best practice are two different things.
>
> But unless you're quite certain that no code has done the equivalent
> of
>
> delete person2.address,
>
> you still need something like that to ensure your code won't fail
> horribly.
Object.seal(...)
> The point is simply that JS is a class-free language. You can
> simulate classes to some degree, but it's never an exact match with
> what's available in class-based languages.
I don't recall saying anything about classes nor their simulation nor
any feature that is necessarily shared with them. You seem to be
trying to present a Straw man.
--
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]
