Hey, people, just a tip about communication to begin with :
See the post new thread button? I don't want to sound too humble, but discussions like
"32 liners", "64 liners", and "20 liners rules" are GREAT initiatives.
They're not intrusive, lacking in respect to anyone, including www.ozones.com who owns the place.
The only semi rule of thumb I know of consists in trying to separate topics - that's why I dare
to hit the "post new thread" button : one great thing about communication is that you can test any part of it
as long as it remains playful enough.
(so friggin' post about your initiatives, for the love of bacon!)
-----------------------------------------------------------------------------------------------------
With this in mind, the topic at hands are some special, advanced javascript constructs
that are vastly questionable in terms of lines count. Questions I'd like to adress,
and I do not have specific knowledge enough to be aware of all possibilities :
1) chained functions and try/catch operations have been questioned : any other case seems worthy of analysis?
2) case-by-case debate
3) are there other changes to the javascript friendly compos we want for February?
I think the question about chained functions is should be quite easy to settle:
code:
function f(someval){
return somecodedoingsomethingwithsomeval;
}
var
finalval=f(initialval);
is equivalent to
code:
var
finalval=function(someval){
return somecodedoingsomethingwithsomeval;
}(initialval);
Thus, they should both count for the same amount of lines. The rules we have set about function declarations makes the first code count as two lines. I'd therefore argue that the second code should also count for two lines.
quote: liorean said:
The rules we have set about function declarations makes the first code count as two lines. I'd therefore argue that the second code should also count for two lines.
Agreed.
However something interests me. What do you think of the following code:
From: Cranleigh, Surrey, England Insane since: May 2003
posted 01-24-2008 14:28
Hmmm...I think it would have to be...what about:
code:
function f(m) {
eval(m);
}
((condition) && !f("alert('hello')") && !f("alert('Rule')"))?f("alert('abuse!')"):f("alert('....twice!')");
Then again...there are always going to be arbitrary ways to cram anything into 20 lines...hell, some code compression algo's automagically compress everything into 1 line....I think the idea should be to go with the spirit of the rules. Each of the 20 lines is meant to convey one idea, one calculation or something similar. So if you can find a clever way to compress two ideas into one (the standard trick for setting posTop and posBottom on one line), great...but if you do something that's blatantly meant to be 2...it's naughty. But hey, the whole thing's a fun game anyway, so maybe leave it up to the judge that month to consider how moral the code is too?
Funny, I was going to bring up that chaining of function calls through the shortcut evaluation operators. Yes, I think we should only count it as one line, because it would be ridiculous to make so intricate rules that you actually prevent this atrocity from being counted as a single line while still making sensible one liners using the shortcut evaluators count as only one line. It opens up for some potential exploitation of the rules, yes, but I can't recall the rules dealing with it any better earlier. Anyway, I think there's some things that aren't worth detailing, where it's better to simply go by a case-by-case discussion.
Another example is this:
code:
var a=[null,'param1,param2,param3','alert(param1);alert(param2);alert(param3);return function(){return [param1,param2,param3];}'],
s=Function.prototype.call.apply(Function,a)('This','is','madness!')().join(' ');
It's a two liner, right? One line is an array initiator, one line is a complex series of function calls.
If we really want to deal with that, we have to special case function calls like eval, Function, setTimeout, setInterval. There's also numerous ways of getting the same effects using events, the DOM, URIs etc.
function f(lop){
return function(rop){
return Number(lop)+Number(rop);
};
}
var n=f(1)(2);
I think it should count as three lines. It could be used with an arbitrary but finite depth using some old Scheme tricks, but you still pay at least one line per level and one for the initial invocation.
wrayal: Actually I never used jQuery, or any JS framework/library, but from the time I was coding in C/C++ I always liked chained calls and that a big part of jQuery's syntax. It ends up with things like:
code:
$("p.surprise").addClass("ohmy").show("slow");
3 function calls, 1 line
code:
$("#orderedlist").find("li").each(function(i) {
$(this).append( " BAM! " + i );
});
Well, you get the idea. It can be "abused" to execue a lot of things on one line. So how do you guys feel about that type of syntax in the context of 20 liners ?
But at the end of the day, Arthurio and Iron Wallaby are dead right.
Poi: Well, actually in the 20 liner you'd have not only the function calls, but the actual implementation code as well. Now tell me those chained 10 function calls aren't actually many more lines if you count the implementation behind them
Using any technique that essentially eliminates or greatly reduces the boundaries set for the challenge should be considered abuse. Using these techniques in moderation shouldn't be considered abuse.
edit: oops that sounds weird, anyone care to rephrase that for me?
Poi: Built-ins or host functions, you mean For the use of the word "native" that the ECMAScript spec uses, a native function is one defined using ECMAScript, not one that is part of the host environment.
Look at the uses of call/apply/Function/join in my evil two-liner earlier, you could use a few built ins that way. I don't think it's cheating in any way, using built ins in general like that. However, in my specific example those function calls eliminated a lot of user code by embedding it into a string which got compiled as a function body. This specific use to eliminate executable code from the count is what I would call cheating, on the other hand.
You can't really achieve anything of note using only the ECMAScript built-ins. You can only chain functionality so far before you enter a point of no return. Nothing in the ECMAScript standard library or the DOM and BOM is inherently chainable in the way JQuery allows chaining. If you wanted long chains, you'd have to insert stuff that increased your line count to link the chains together.
quote:However, in my specific example those function calls eliminated a lot of user code by embedding it into a string which got compiled as a function body. This specific use to eliminate executable code from the count is what I would call cheating, on the other hand.
Agreed.
By "native" I meant implemented by the browser, not in JavaScript.
code:
/* */ function fn( func )
/* */ {
/* C */ return function()
/* */ {
/* D */ return func.apply( this, arguments )||this;
/* */ }
/* */ }
/* A */ for( chainThat in {methodA:1,methodB:1} )
/* */ {
/* B */ anObject.prototype[chainThat] =
/* E */ fn( anObject.prototype[chainThat] );
/* */ }
Can be used to make native methods, on a same type of object/element, chainable
Only if they propagare the this value, or at least propagate an object of the same type. Most built-ins don't, which is why I was stating
quote:You can only chain functionality so far before you enter a point of no return. Nothing in the ECMAScript standard library or the DOM and BOM is inherently chainable in the way JQuery allows chaining.
Of course, you get around that since you can apply it to all object types. (Still breaking on null or undefined return values, though...)
quote:Only if they propagare the this value, or at least propagate an object of the same type. Most built-ins don't
Whic is the very purpose of the code snippet I'm talking about : To "extend" some native functions and have them propagate this when they don't return anything ( or anything assimilated to false )