Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: new Java lambda syntax Date: Wed, 14 Sep 2011 07:40:06 -0700 Organization: albasani.net Lines: 76 Message-ID: References: <9j3vj8-aqe.ln1@news.simpsonst.f2s.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 1BNaaFrhRjgikk1jyRXuctOFaXd1eWLLwXYycpiLRehaFTv0YQ0uGOykORfRVINktQQzaZZwv0ZysVUuOOQHLA== NNTP-Posting-Date: Wed, 14 Sep 2011 14:40:10 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="BDMBwoHrD30/mM6GGF88xDqpvobnORMtpReiFYhUYqx8jwk7IHFOgi77EGzJGpie+gz5RLw5tKkQAdPeaJXnp/w+HItxT81PIc7BgBfeMf/sbyOJtyBXuu2qFsAjRHRj"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 In-Reply-To: Cancel-Lock: sha1:ybq/Cd5gSHZ74VlWYLnKbgLV4tk= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8019 On 9/14/2011 2:29 AM, Arved Sandstrom wrote: > On 11-09-13 11:36 PM, Joshua Cranmer wrote: > [ SNIP ] > > JS doesn't support OO in the classical >> way, and how `this' gets resolved is actually handled by the way you >> call the method. > [ SNIP ] > > I point out somewhat tongue-in-cheek that JavaScript indeed isn't > "classical" OO, since it's not class-based OO; rather it's object-based > (prototype-based) OO. I think the argument can be made that it's a purer > and more fundamental object-orientation, since you dispense with the > class baggage. > > I confess to being seriously biased: lots of experimentation with > non-Web JS programming, and Self and Lua programming. And certainly some > strengths of Scala lead one to think more about runtime objects and not > so much about instances of classes. > > Even though "classical" is strictly speaking a correct description of > class-based OO, I sort of prefer "dominant" or "original". Or just > "class-based". Again revealing my bias, I think class-based OO has done > some degree of harm to object-oriented programming, so I am reluctant to > associate it with a word like "classical". > yeah. my own language started out as pure Prototype-OO, but has since implemented more of a hybrid model (partly influenced by ActionScript). in this model, one can have plain dictionary objects (traditional JS-like objects), dynamic class objects (which look more like class/instance objects, but can have fields added dynamically), and plain class objects (implement class/instance, objects are fixed-form / may not be structurally altered at runtime). whether the language behaves more like static or dynamic typing, or is early or late-binding, has more to do with ones' choice of types. var i:int; //behaves more like a statically-typed integer var x; //is more dynamically type. var obj:SomeObject; i=3.0; //will coerce the type to an integer x=3.0; //will simply assign the value i="3"; //bad/error x="3"; //yep, now x holds a string ... x.someMethod(); //late-bound / duck-typed obj.someMethod(); //early-bound (sort of) in a technical sense, the VM doesn't support early binding in the JVM sense (where the method call's type/... is defined in the bytecode ops), rather it is theoretically bound at load-time/"prejit-time" (in reality, this is an optimization feature, and is technically optional). a partial merit of delaying type-handling until load-time or run-time is that it allows a lot more flexibility (and greatly simplifies things like having a semi-transparent C FFI without needing explicit compiler support). one can also do many more things which look like dynamic and duck-typing without incurring nearly as many costs related to run-time type-checking and similar as well (to the codegen, they may still appear as static types). a downside though is that a lot more of the "work" is shifted onto the VM, so "a simple naive bytecode interpreter which is also really fast" is mostly ruled out. however, this issue is mostly eliminated by using a JIT, and even with its slowdown, the plain interpreter is often "plenty fast enough" for most tasks. or such...