By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,984 Members | 1,016 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,984 IT Pros & Developers. It's quick & easy.

EXAMPLE OF ENTIRELY UNNECESSARY REBUTTALS: Grant Wagner Observations

P: n/a
An OUTSTANDING example of a rebuttal. Worth a glance. Rather long,
OBVIOUSLY feel fee to dismiss it entirely if not interested.

But this habit of the rebuttals must go to a stop (forgive odd english,
which is NOT my native tongue), if you consider what TYPE of rebuttals we
often see here.

I am truly still impressed that persons here STILL make rebuttals and don't
know the simplest courtesy guidelines.

My own: an user asks for a question, I get in if I can, answer HIS/HER
question with MY personal suggestion, and I do NEVER meddle with the others
who are kind enough to respond to him/her.
If I see an answer with a wrong code, I don't jump on that, I JUST state MY
OWN answer and I don't even metnion the answers of the others I found
uncorrect or questionable. I STICK to this rule. N_O R_E_B_U_T_T_A_L_S .
EVER!

Of course, I answer when others don't follow these simple courtesy norms and
use online groups only as occasions to find ways to bolster their evidently
shaky self esteem by attacking the codes of the others EVEN if NO error is
in them.

As for the following, see what ABSURD observations: not one single mistake
in the code, yet this person is able to issue a whole rebuttal ALL focused
on STYLE CODING PREFERENCES - like "oh god! don't add brackets after
typeof" - go imagine....

I am really annoyed by this habit of the rebuttals.

Excerpts enclosed by ######### are quotations. Within them lines starting
with the > are my "offending" code that needed to be bashed so much oh so
much, and see WHY...

from:
http://www.forum4designers.com/archi...4-5-77131.html
---------------
#########
<script language="JavaScript" src="../miscella.js"> <script type="text/javascript" src="..."></script> </script>
<script><!-- <!-- not needed and not recommended.
#########

For a few among us it is customary to add them. You know, that thing of a
browser with js disabled ya know.... You know yes...?

The type="text/javascript" is a RELATIVELY recent recommandation that a
purist may follow, but it adds or subtracts nothing to the functionalities.
The scripts work, details of the script tag interest me a bit less,
especially after I have made a 120kb long page of codes documentation -
which is ALL for FREE.
######### function findSheet(characteristic, characteristicIsHREF){
if(!document.getElementById || !document.styleSheets.length){ return
false; }; Code blocks do not require trailing semi-colons. This mistake is repeated
throughout the code.
#########

Irrelevant rebuttal, I use them for MY own purpose: when a curly bracket
ends with a semi-colon, it means to MY EYES it is not the closing bracket of
a for or while loop but the end of a conditional statements set.

As long as you write functions that are 4 lines long you may not need
private conventions to spot them aside from indentation, as soon as you do
you may enforce a few of your own CONVENTIONS - which are not detrimental
in the least to the functionalities.
Irrelevant comment and rebuttal that didn't figure out there could be a
UTILITY for the coder.
#########
typeof is an operator, not a function. This can be made much more clear by
elminating the brackets from the operand: "typeof characteristic". This
mistake
it repeated throughout the code.
#########

typeof is an operator, and YET it is clearer to my eyes to add brackets
whenever possible, for instance i never do things like
if(some)varx=vary;
I always add brackets
if(some){varx=vary}
The same line of reasoning you adopt for the above rebuttal you can adopt
also to rebut that other habit of mine. I USE PARENTHESIS EXTENSIVELY. My
choice.

You're making rebuttals on unsubstantial points criticizing the personal
habits of another javascripter. That typeof is not a function we all know:
is a conceited assumption by you assuming that since I added brackets I
would have meant I thought it was.
Irrelevant comment, molreover based on wrong presumptions.
######### this.characteristicIsHREF = (characteristicIsHREF)?1:0; Why use 1 and 0 when you test characteristicIsHREF as a boolean later?
#########

I don't check anywere later to see if it is a boolean. Review better the
codes. You're arguing a non existant point here.

######### var reg=new RegExp();
reg.compile("\\b"+arg2+"\\b","g");
return reg.test(arg1); You don't need to construct a new RegExp() object, then compile it, then
test
it, you can do it all in a single operation:
return (new RegExp("\\b"+arg2+"\\b","g")).test(arg1);
#########

"There is more than one way to do it" - mine is not the better, yours is not
the better. They are just ways.
Irrelevant punctilious comment. The compile method EXISTS TO BE USED in
javascript, SO I CHOOSE TO USE IT. Period.

######### else{
return(arg1==arg2)?true:false; You're using a conditional to return the boolean result of an expression
that
returns a boolean:
return (arg1 == arg2);
#########

True, but so what? Can't I code with half a line more if it is clearer to my
eyes? what's the real difference, 10bytes more? Strange that you don't argue
here too that return "is not a function" LOL :-)))

######### return (typeof(objectToReturn)=="undefined")?
false:new Array(
objectToReturn,
i,
objectToReturn.href.substring( objectToReturn.href.lastIndexOf("/")+1 ),
objectToReturn.href
); What an ugly incomprehensible conditional. If you're going to include
unneeded
semi-colons at the end of code blocks, and use unneeded brackets on the
typeof
operator, why not use a few more characters to make it clear what you're
doing?
if (typeof objectToReturn == "undefined") {
return false;
} else {
return [
objectToReturn,
i,
objectToReturn.href.substring(objectToReturn.href. lastIndexOf("/") + 1),
objectToReturn.href
];
}
#########

Here you are objecting against the VERY SAME PRACTICE YOU YOURSELF
recommended earlier. In other terms, damned if you do damned if you dont
ahahahaahaha.
I don't recommend one practice, and I use both as I find fit.
Irrelevant and contradictory rebuttal. You first argue for a shortcut
return(z==y), then you complain about another shortcut.

######### optionalIndex=(!optionalIndex)?1:
(obj.rules)?
obj.rules.length : obj.cssRules.length; Nested conditionals? Lovely. Could you write code that is more difficult to
maintain?
#########

I use them extensively and I REGRET that PHP doesn't allow nesting them. The
fact YOU can't maintain THAT code or find it difficult to maintain it
doesn't imply others have your same limitations. I can maintain that better
with nested conditional shortcuts, and since it is ME and NOT you who has to
maintain them, I follow the functional guideline that I find ft to me and
not to you.

Irrelevant comment on personal tastes or intellectual limitations: you have
yours I have mine, and I maintain my own codes as I MYSELF find them easier
to maintain. I have to maintain them, NOT you, so stick to YOUR business and
maintain YOURS.

######### off=(!off)?true:false; Excuse me?
off = !off;
#########

Nope. In my scripts often I allow for arguments being passed also in data
type formats which are not the expected ones. Javascript is not java,
incoming arguments could be other data type than the expected one. I use
those statements to reconvert types to an expected format in case something
incoming goes awry.
You find
off = !off;
clearer
I find
off=(!off)?true:false;
clearer.

You keep contending all the while with the rules of maintenance clarity that
YOU find better. I don't contend yours, but none of your points make a
point: both expressions are equally valid, yourn personal taste has no
technical relevance and your comment is once again an irrelevant rebuttal of
NO practical substance.

######### obj.disabled=(off)?false:true; obj.disabled = !off;
#########

Same as above. YOU keep arguing that YOUR syntax is clearer. I don't find it
clearer. You want to use it? use it and don't bother others who have
personal preferences that do not meet your coding HABITS.

######### indexOrObject=(indexOrObject && !isNaN(parseFloat(indexOrObject)))?
parseFloat(indexOrObject):
(typeof(indexOrObject)=="object")?indexOrObject:0; Wonderful, more incomprehensible nested conditionals. Not only are they hard
to
read, you're doing way more method calls and tests then are required:
var indexOrObjectFloat = parseFloat(indexOrObject);
var indexOrObjectIsObject = (typeof indexOrObject == "object");
#########

AGAIN: I use EXTENSIVELY nested conditionals, I find them MORE readable and
the fact you prefer a swet of if/else to shortcuts doesn't affect in the
least the codes and what they do, and nmot even their speed as a matter of
fact.

Irrelevant gratuitous rebuttals still starting by the assumptions YOUR
pesonal preferences are THE guidelines. I never thought mine couold have
been, it seems for you it goes without discussion your would have been...
wow.

######### var isObj=(typeof(indexOrObject)=="object")?1:0; Again, assigning 1 or 0 based on an expression that returns a boolean to
what is
essentially a boolean flag.
var isObj = (typeof indexOrObject == 'object');
#########

Your opinion, disguised as a rule. You find your statement clearer, I don't
find it clearer and I use mine on MY scripts. So what? Your point is?
Notre I add the brackets to typeof, as you contended earlier. I find them
clearer. Again, PERSONAL opinions. You just vest them as rules, I don't do
that with mine.

######### output[OL][2][ ++output[OL][2].length-1 ]=grab;
output[OL][3][ ++output[OL][3].length-1 ]=current; Oh my god.
Isn't ++value - 1 == value?
so:
output[OL][2][ ++output[OL][2].length-1 ]=grab;
output[OL][3][ ++output[OL][3].length-1 ]=current;
is exactly the same as:
output[OL][2][output[OL][2].length]=grab;
output[OL][3][output[OL][3].length]=current;
#########

Not it isn't. Your codes could produce Objects not arrays. It is my habit,
when I increase an array, to make it clearer its NUMERICAL indexed key
nature, to discriminate it from an associative indexed object, by always
using ++. I find it clearer to my eyes, and it is 101% legitimate - a few
EVEN recommend it, go fancy...

Again, you argue on UNSUBSTANTIAL points, calling in even God to support
your position. But that's an hypothesis I don't need when I just deal with
javascript. I call in God's names for serious things ONLY.

######### object=(!isNaN(parseFloat(object)))? parseFloat(object):object;

You're calling parseFloat() twice if object ends up being a number, and
you're
doing an unnecessary assignment if it's not.
#########

There is an alternative:
object=parseFloat(object)
then the conditional.

I prefer keeping all in a shortcut line, and calling twice a parseFloat
doesn't bother me, I am not interested in saving an half of an half of a
picosecond on a pentium 1200.

#########
I could go on, but I can't be bothered telling you how to fix your horrible
code
any longer.
#########

You have a conception of fixes that makes no sense. The code works, you call
AESTHETICAL requirements that follow YOUR own personal tastes a "fix" - you
fix bugs, not style preferences:
tupeof obje
and
typeof(obj)are not in a reciprocal relation of fix versus bug.

#########
Why are there 100 lines of inline Javascript on that page? You enjoy forcing
your users to download that much Javascript everytime they visit the page
it's
on?
#########

Because it is MY personal website, where I offer 120 files of an average
75Kb of documentation for FREE to wheoever may want it. So if one doesn't
weaqnt them, one doesn't get them, if one waqnts them, one gets them for
FREE. Others for 120 files of codes would have started asking money.
Probably your case.

Alberto Vallini, who codes as HE find fit on HIS OWN websikte, especially
when he gives all HIS codes for FREE.
http://www.unitedscripters.com/


Jul 23 '05 #1
Share this Question
Share on Google+
23 Replies


P: n/a
In article <28**********************@news3.tin.it>, no****@nospam.nospam
enlightened us with...
An OUTSTANDING example of a rebuttal. Worth a glance. Rather long,
OBVIOUSLY feel fee to dismiss it entirely if not interested.


<snip crap>

You took up 332 lines to complain about someone else who corrects mistakes or
offers opinions on solutions people post?

This is Usenet. We have discussions about solutions to problems and whether
solutions are good or bad. Many of us LIKE this. You don't. Whoop-de-effing-
do.
Deal with the fact that people actually have disagreements, arguments,
debates, and conversations here or go join a moderated group and let us learn
in peace.
If you really hate a person or someone consistently posts things that
irritate the holy hell out of you, use your killfile.

--
--
~kaeli~
Support your local medical examiner: die strangely!
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #2

P: n/a
It is a free forum, where a thread can take up much more than one single
file like mine. Just pick 70% of threads here and each of them amounts to
MUCH more than the 300 lines you got impressed by. That rebuttal itself
took 120 lines to stgress nothing. An average thread is MUCH longer. Pick
one at arndom, odds are it is.

I don't like rebuttals especially when made on style CUSTOMS (case in point,
precisely), and when I can I want to make a move to show how detrimental
they can be. Taking the initiative of the rebuttals is a practice that I
deem should start to be condemned.

If you feel like praising it so to encourage its spreading for you like it,
I respect your choice.

Yet you can tell a rebuttal from what you call "whether solutions are good
or bad" from the fact the rebuttal is clearly tailored and crafted not to
gently state a point but to vilify the other person, often with clearly ad
personam statements - the need that makes a rebuttal necessary to the eyes
of someone is not an intellectual technicality as you imply ("whether good
or bad") , but is spurrred by an emoltional issue. Rebuttals are not
intgellectual contgributions, and as such we'd condemn the practice - for it
is exactly not good. Otherwise "whether solutions are good or bad" is a
point that can be implemented without belittling anybody for the sake of it.
That's called a rebuttal.

I am expecting my choice to stress the shortcomings of the rebutals
malpractice get to be respected as well as the one that finds them perfectly
legitimate in contents and form.

PS note that I am not making suggestions or giving advice to you. Noticed?

ciao
Alberto
http://www.unitedscripters.com/

"kaeli" <ti******@NOSPAM.comcast.net> ha scritto nel messaggio
You took up 332 lines to complain about someone else who corrects mistakes or offers opinions on solutions people post?

This is Usenet. We have discussions about solutions to problems and whether solutions are good or bad. Many of us LIKE this. You don't. Whoop-de-effing- do.
Deal with the fact that people actually have disagreements, arguments,
debates, and conversations here or go join a moderated group and let us learn in peace.
If you really hate a person or someone consistently posts things that
irritate the holy hell out of you, use your killfile.

--
--
~kaeli~
Support your local medical examiner: die strangely!
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #3

P: n/a
Good example of positive intellectual contribution:
------------
var x=(y)?1:(y2?)?2:3;
I would like to suggest using the if-elsee statement blocks, I find nested
shortcut conditionals a bit harder to be read. They work, but I find them
less readable. I'd recommend the other for mere readability.
------------

Example of the same as a rebuttal:
------------
var x=(y)?1:(y2?)?2:3;
Gee what an absurd code, I can't tell you! OH MY GOD! You use it throughout
gee, and you can't even see HOW bad it is. I can't read it! You'd use
conditionals! THAT?s the way to do it!! Oh well, I am fed up with providing
you with my advice to fix your horrible codes.
------------

Can you sense the "slight" difference, and why PRECISELY for the sake of
that "learning" you mentioned we'd start condemning the latter, and
encouraging only the former practice?

Alberto
http://www.unitedscripters.com/
Jul 23 '05 #4

P: n/a
var x=(y)?1:(y2?)?2:3;
a typo ;-)
Jul 23 '05 #5

P: n/a
On Wed, 18 Aug 2004 12:41:34 GMT, Alberto <no****@nospam.nospam> wrote:

[snip]
My own: an user asks for a question, I get in if I can, answer HIS/HER
question with MY personal suggestion, and I do NEVER meddle with the
others who are kind enough to respond to him/her.
If I see an answer with a wrong code, I don't jump on that, I JUST state
MY OWN answer and I don't even metnion the answers of the others I found
uncorrect or questionable. I STICK to this rule. N_O R_E_B_U_T_T_A_L_S .
EVER!
So, are you suggesting that if I post something that is complete rubbish,
no one should correct me? I find that absurd. I'm here to learn just like
everyone else. I make mistakes, frequently, and I'm thankful for every
time I've been corrected.

[snip]
As for the following, see what ABSURD observations: not one single
mistake in the code, yet this person is able to issue a whole rebuttal
ALL focused on STYLE CODING PREFERENCES - like "oh god! don't add
brackets after typeof" - go imagine....
I was once told that too, though without the added dramatisation. I forget
the reason given, but it was acceptable at the time. The only instance
where I use parentheses is when I'm evaluating an expression, rather than
an identifier.

[snip]
#########
<script language="JavaScript" src="../miscella.js"> <script type="text/javascript" src="..."></script>
</script>
<script><!--

<!-- not needed and not recommended.
#########

For a few among us it is customary to add them. You know, that thing of a
browser with js disabled ya know.... You know yes...?


That's the point - even script-disabled browsers won't confuse the
contents of the script. The historical reason why the SGML comment
delimiters were used, was that browsers produced before the SCRIPT element
was introduced obviously wouldn't understand what it meant. The HTML
specification states that if a user agent encounters an unknown element,
the element is to be ignored and its contents parsed normally. In the case
of the SCRIPT, that meant rendering the code.

For a long time now, the SCRIPT element has been part of the language. All
browsers in use understand what a SCRIPT element is so they won't render
the contents, even if scripting is disabled.

If you are concerned about scripts and old browsers, place the script in
an external file and use the src attribute.
The type="text/javascript" is a RELATIVELY recent recommandation that a
purist may follow, but it adds or subtracts nothing to the
functionalities.
That's incorrect. For the record (again - yes, I've done this before):

The SCRIPT element was introduced in the HTML 3.2 Recommendation,
1997-01-14. Then it was simply a placeholder, along with the STYLE
element, to be fully defined at a later date. The purpose was to inform
browser manufactures that the new element was coming and browsers
shouldn't render the contents. In theory, that means that every browser
made after the release of the specification doesn't require comments.
Obviously, some will have continued to ignore the element, but even so,
they will be at least six years old!

The SCRIPT element was properly defined in the next HTML release, the HTML
4.0 Working Draft, 1997-07-08. Here, the SCRIPT element was given the
type, language, and src elements. All of them were valid, but none of them
were required.

After another draft, HTML 4.0 become a Proposed Recommendation on
1997-11-07. Here, two more attributes were added: charset and defer.
Moreover, the type attribute was modified to become required. That means
that

<script type="<CONTENT-TYPE>">

has been the minimum allowed for a SCRIPT element for almost seven full
years. Your argument that it is relatively recent is therefore wrong,
plain and simple.

Continuing the evolution, the for and event attributes were added when
HTML 4.0 became a full Recommendation on 1997-12-18. For the moment
though, both remain reserved and undefined in HTML (though Microsoft
thinks differently).

When the specification was revised 1998-04-24, the language attribute
removed from the Strict DTD and declared formally deprecated. I say
"formally deprecated" because although it remained in the DTD, it was
listed as deprecated in the SCRIPT element's description as early as the
second Working Draft, 1997-09-17 (the one I skipped earlier).

Basically, there hasn't been a reason to use either SGML comment
delimiters, or the language attribute for a long time. Nor has there been
any reason not to use the type attribute.
The scripts work, details of the script tag interest me a bit less,
especially after I have made a 120kb long page of codes documentation -
which is ALL for FREE.
I don't see what relevance that has to writing correct HTML.
#########
function findSheet(characteristic, characteristicIsHREF){
if(!document.getElementById || !document.styleSheets.length){
return false; }; Code blocks do not require trailing semi-colons. This mistake is
repeated throughout the code.
#########

Irrelevant rebuttal, I use them for MY own purpose: when a curly bracket
ends with a semi-colon, it means to MY EYES it is not the closing
bracket of a for or while loop but the end of a conditional statements
set.


However it could confuse a beginner. I do understand and appreciate your
point, though. The editor I use (NetBeans) highlights matching parentheses
(), brackets [], and braces {}.

[snip]
#########
typeof is an operator, not a function. This can be made much more clear
by elminating the brackets from the operand: "typeof characteristic".
This mistake it repeated throughout the code.
#########

typeof is an operator, and YET it is clearer to my eyes to add brackets
whenever possible, for instance i never do things like
if(some)varx=vary;
I always add brackets
if(some){varx=vary}
The same line of reasoning you adopt for the above rebuttal you can
adopt also to rebut that other habit of mine. I USE PARENTHESIS
EXTENSIVELY. My choice.

You're making rebuttals on unsubstantial points criticizing the personal
habits of another javascripter. That typeof is not a function we all
know: is a conceited assumption by you assuming that since I added
brackets I would have meant I thought it was.
Irrelevant comment, molreover based on wrong presumptions.
Whilst it may be clear to you and everyone else that knows the language,
it is not clear to a beginner for the same reason. You can't teach someone
by confusing them, and we aim to teach posters in the group.
#########
this.characteristicIsHREF = (characteristicIsHREF)?1:0; Why use 1 and 0 when you test characteristicIsHREF as a boolean later?
#########

I don't check anywere later to see if it is a boolean. Review better the
codes. You're arguing a non existant point here.


I'll put that down to English as a second language. He didn't say, check
to see IF characteristicIsHREF is a boolean, he said that you use it AS a
boolean.

Also, I don't believe you intended to use that code as it stands. The this
operator, in the context above, is the global object. That line creates a
property of the global object, characteristicIsHREF, and assigns it 1 or
0. If you want to convert the value of characteristicIsHREF to a boolean,
it's better to write

characteristicIsHREF = Boolean(characteristicIsHREF);

or

characteristicIsHREF = !!characteristicIsHREF;

There are several other instances where you do this (though without
writing to the global object). Of course, it's not necessary anyway. An if
statement will evaluate the value just the same as ?: would.
#########
var reg=new RegExp();
reg.compile("\\b"+arg2+"\\b","g");
return reg.test(arg1); You don't need to construct a new RegExp() object, then compile it, then
test it, you can do it all in a single operation:
return (new RegExp("\\b"+arg2+"\\b","g")).test(arg1);
#########

"There is more than one way to do it" - mine is not the better, yours is
not the better. They are just ways.
Irrelevant punctilious comment. The compile method EXISTS TO BE USED in
javascript, SO I CHOOSE TO USE IT. Period.


However, it only has an advantage if you will use that regular expression
often. According to the code above, the complied object will be destroyed
immediately after anyway, so it's a waste of time.

I'll also add another reason not to use it: whilst compile() might exist
in JavaScript, it doesn't exist in ECMAScript, the standardized language.
Calling the method may result in an error.
#########
else{
return(arg1==arg2)?true:false; You're using a conditional to return the boolean result of an expression
that returns a boolean:
return (arg1 == arg2);
#########

True, but so what? Can't I code with half a line more if it is clearer
to my eyes? what's the real difference, 10bytes more? Strange that you
don't argue here too that return "is not a function" LOL :-)))


Don't be facetious.

[use of conditional operator]
Here you are objecting against the VERY SAME PRACTICE YOU YOURSELF
recommended earlier. In other terms, damned if you do damned if you dont
ahahahaahaha.
I don't recommend one practice, and I use both as I find fit.
Irrelevant and contradictory rebuttal. You first argue for a shortcut
return(z==y), then you complain about another shortcut.
No, the point is that the conditional operator can be extremely confusing
as it doesn't provide an means of clarity, unlike the braces of an if
statement.
#########
optionalIndex=(!optionalIndex)?1:
(obj.rules)?
obj.rules.length : obj.cssRules.length; Nested conditionals? Lovely. Could you write code that is more difficult
to maintain?
#########

I use them extensively and I REGRET that PHP doesn't allow nesting them.
The fact YOU can't maintain THAT code or find it difficult to maintain
it doesn't imply others have your same limitations. I can maintain that
better with nested conditional shortcuts, and since it is ME and NOT you
who has to maintain them, I follow the functional guideline that I find
ft to me and not to you.


Once again, you're ignoring the fact that other people will be trying to
understand you code, especially as it seems the point of your website is
to demonstrate the code you've produced.

[snip]
#########
off=(!off)?true:false; Excuse me?
off = !off;
#########

Nope. In my scripts often I allow for arguments being passed also in
data type formats which are not the expected ones. Javascript is not
java, incoming arguments could be other data type than the expected one.
I use those statements to reconvert types to an expected format in case
something incoming goes awry.


And what's your point? As I already stated, the condition operator just
converts a value to a boolean before evaluating it. The negation operator
(!) will do exactly the same thing, whilst making it clear that the only
operator is the inversion of off. Adding a condition complicates things as
you then have to see what that's doing.

[snipped remaining comment and duplicate examples]
#########
output[OL][2][ ++output[OL][2].length-1 ]=grab;
output[OL][3][ ++output[OL][3].length-1 ]=current; Oh my god.
Isn't ++value - 1 == value?
so:
output[OL][2][ ++output[OL][2].length-1 ]=grab;
output[OL][3][ ++output[OL][3].length-1 ]=current;
is exactly the same as:
output[OL][2][output[OL][2].length]=grab;
output[OL][3][output[OL][3].length]=current;
#########

Not it isn't. Your codes could produce Objects not arrays.


How? The length property is a number, thereby always resulting in an array.
It is my habit, when I increase an array, to make it clearer its
NUMERICAL indexed key nature, to discriminate it from an associative
indexed object, by always using ++.
That doesn't make much sense. If the value is a string, using ++ won't
change that. It'll just result in an error or some strange bugs in your
code.
#########
object=(!isNaN(parseFloat(object)))? parseFloat(object):object; You're calling parseFloat() twice if object ends up being a number, and
you're
doing an unnecessary assignment if it's not.
#########


Without understanding the logic behind that code, I can't comment.

[snip]
#########
Why are there 100 lines of inline Javascript on that page? You enjoy
forcing your users to download that much Javascript everytime they visit
the page it's on?
#########

Because it is MY personal website, where I offer 120 files of an average
75Kb of documentation for FREE to wheoever may want it. So if one
doesn't weaqnt them, one doesn't get them, if one waqnts them, one gets
them for FREE.
If scripts are separated into organised files, and cached, by the user,
they won't have to download everything if you just modify the HTML. That's
part of the point of external JavaScript.
Others for 120 files of codes would have started asking money. Probably
your case.


I would say that's a rather unfair attack. He questions your code, so you
question his ethics?

[snip]

By the way, this group isn't for rants about personal attacks. I thought
you were posting about a general group attitude, but you're not. You're
just posting about one reply to you.

Mike
Apologies for the long post.

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail
Jul 23 '05 #6

P: n/a
Hallo Michael, happy you found the thread interesting though it seems you
miss my point: I am making a point against the habits of rebuttals:

########################quote
Good example of positive intellectual contribution:
------------
var x=(y)?1:(y2?)?2:3;
I would like to suggest using the if-elsee statement blocks, I find nested
shortcut conditionals a bit harder to be read. They work, but I find them
less readable. I'd recommend the other for mere readability.
------------

Example of the same as a rebuttal:
------------
var x=(y)?1:(y2?)?2:3;
Gee what an absurd code, I can't tell you! OH MY GOD! You use it throughout
gee, and you can't even see HOW bad it is. I can't read it! You'd use
conditionals! THAT?s the way to do it!! Oh well, I am fed up with providing
you with my advice to fix your horrible codes.
------------

Can you sense the "slight" difference, and why PRECISELY for the sake of
that "learning" you mentioned we'd start condemning the latter, and
encouraging only the former practice?
########################unquote

So, are you suggesting that if I post something that is > complete rubbish,

That's the point, my codes are not complete rubbish simply because I use
shortcut conditional operands - which is what 90% of the arguments amount
downright to.

MORE significantly, one can state his points in a civilised manner without
meddling personal comment ("my god" "rubbish" "awful") - you don't do that
for instance: since you are not doing it, why you put yourself on the same
ground of those who do it?
where I use parentheses is when I'm evaluating an expression, rather than
an identifier.
Your option which I don't contend. It is neither better nor worse, it is
just your way. I would never cross that way of yours to say to you that
you're ridiculous because you do it in a way I am not used to do it - both
achieveing the SAME with MINIMAL differences.

That's the point - even script-disabled browsers won't confuse the
contents of the script. The historical reason why the SGML comment
delimiters were used, was that browsers produced before the SCRIPT element
I myself don't always use them, and yet there is a custom to use them. I
can't see why making of a custom that has been our legacy for 10 years
should be turned into a reason to stress it as a "bug" which needs a "fix":
ours, needless to say.

has been the minimum allowed for a SCRIPT element for almost seven full
years. Your argument that it is relatively recent is therefore wrong,
plain and simple.
See perhaps it is because I am italian and we have an habit to be gentlemen,
but I would never use those wordings to you as my personal INITIATIVE, For
instance, how about if I would have replied to your point (which I am not
doing now, I just make an example of how another could have done it) "ah
that is stuff for purists who have more time to spend for mere theory rather
than for making real webpages, I let them to their needless, plain and
simple, theoretical trims for browsers that exist only on then paper"

I don't see what relevance that has to writing correct HTML.
It IS correct HTML. It doesn't mean to be XHTML. I am flexible enough to
understand that if a page of 100 kb has a wrong closing tag or a comment tag
in a script, that is DEFINITELY nothing to blast a page for.
I am surprised I seem to be the onlyh one in this discussion with this
BAANAL MENTAL FLEXIBILITY.

If I see a commented out script tag, I don't argue it is "writing wrong
html" - browsers work fine with it, to me it is fine. Most of all, I would
never get such a nuisance as an occasion to attack personally somebody and
calling his or her code rubbish shit god's sake awful abomination - all
those adjectives for a couple of details.

If you find that ok, I resspect your opinion. Just be sure you won't come on
ME with that O.K? :-)


However it could confuse a beginner. I do understand and appreciate your
point, though. The editor I use (NetBeans) highlights matching parentheses
I don't care for beginners. My codes can be USED by beginners. I document
the arguments how they have to be passed, the functions or methods how they
have to be INVOKED for them. But that's all for them.

Whoever is actually meddling with the codes is ALREADY assumed has having
enough understanding of javascript to be not confused in the least by
shortcut conditionals.
Also, my website is NOT for beginners actually, I state in the index page,
just for the RECORD:

"Scripts for advanced purposes so they are unsuitable for apprenticeships or
lazy webmasters looking for a way to get paid without working."

Statement at:
http://www.unitedscripters.com/list.html
Whilst it may be clear to you and everyone else that knows the language,
it is not clear to a beginner for the same reason. You can't teach someone
by confusing them, and we aim to teach posters in the group.
Same answer as before Mike.
I'll put that down to English as a second language. He didn't say, check
to see IF characteristicIsHREF is a boolean, he said that you use it AS a
boolean.
To me that's fine. If a variable gets assigned 1, I can check
if(variableName)
I find it 100% ok, javascript is NOT Java, is not strongly data typed. We're
speaking of javascript. I can assign a valuje and check it as a boolean.
Languages do that all the time if(0) amounts to false as well as if(false)
amounts to false. So what?

it's better to write

characteristicIsHREF = Boolean(characteristicIsHREF);

or

characteristicIsHREF = !!characteristicIsHREF;
That you find that better is ok to me. I would also like for instance to use
things like:
!==
or
===
which I am aware of. Yet my personal habit is of preferring shortcut
conditionals. Insisting on this personal preference while at the same time
admitting that both work, make little sense Mike.

Let me stress: I appreciate your code, it works. I don't deem it either
better or worst. YET I use mine, which works as well, and which produces no
errors as well, and I STILL find to MY EYES clearer a ()?: set than a !!var
set.

So, why arguing on personal preferences and taking them as, NOT your case,
an occasion to belittle somebody for sport?

However, it only has an advantage if you will use that regular expression
often. According to the code above, the complied object will be destroyed
immediately after anyway, so it's a waste of time.
I have a conception of time on platforms running a pentium that doesn't
consider these aspects relevant. I would consider them for a Java
application, but for a Javascript saving a tenth of a picosecond doesn't
bother me AT ALL. I have never been after that goal, so judge me after the
goal I state for myself: working code. If one doesn't like iot, one doesn't
take it. Plain and simple isn't it Mike lol :-)
I'll also add another reason not to use it: whilst compile() might exist
in JavaScript, it doesn't exist in ECMAScript, the standardized language.
Calling the method may result in an error.

That is true, but my scrfipt tags carry written language= javascript, so who
runs ECMA won't bother. And now all those who run ECMA please raise your
hand lol :-)))
Don't be facetious.
No? I should cry? LOL :-)

No, the point is that the conditional operator can be extremely confusing
as it doesn't provide an means of clarity, unlike the braces of an if
statement.
As said, I don't care: it is clear to my eyes, and by the way since you
stressed speed (which I don't concern much about), it is faster. ANYWAY IT
IS my CHOICE, IT WORKS, IT IS implemented in all languages AND SO I USE IT.
Period.

Much ado about a legitimate use Mike.
Once again, you're ignoring the fact that other people will be trying to
understand you code, especially as it seems the point of your website is
to demonstrate the code you've produced.
If they are trying that, they must know javascript Mike. My codes ARFE
complex, and also perform EXTENSIVE validations. I NEVER NEVER NEVER deemed
them perfect, but they are not for beginners and have never been meant to be
manipulated by beginners who get confused simply because rather than an
if-else set see a shortcut. I therefore use the syntax I personally prefer.
If you write your codes with the delusional idea your codes are perfect, I
am happy to tell you I have never been so conceited to deem them as such
bedfiore my own eyes. But I can't see why a shortcut ()?: must be the
occasion to repeatedly stress it whould not be used, and on occasion for
personal attacks.
And what's your point?
And what's yours? You don't like shortcuts. Fine.


How? The length property is a number, thereby always resulting in an array.

No Mike! Negative. I want to make clear in my scripts when I am updating an
array and when populating an object. It makes easier for me to revise them
if necessary.
Also, atv times I have to make plurimous assignement to more arfrays, and I
update the index valuenonly once if some condtions meet

loop
bla bla
if(x){L=++lastArray.length-1;
lastArray[L]=x
firstArray[L]=x;
};
end loop

Thence I gvot the habit, and I use it throughout - for a fundamental (NOT
total) consistency of coding is blamed onto me lol

They are at times 500 lines of codes mike... I want to safely discrimninate
when it's an array or an object which I am populating
http://www.unitedscripters.com/scripts/dhtml13.html
change that. It'll just result in an error or some strange bugs in your
code.


Browse all my page codes (which I KNOW you couldn't care less), test them
all in the TEST FORMS, and if after 120 pages you see ONE single error SHOW
UP in the status bar, I will agree with you.

PS if you want to reply again that you don't find shortcut conditionals
readable, I inform you that I have got your point. I appreciate you prefer
conditionals with if else, I don't understand why you hate so much
shortcuts, I will go on LETTING you use YOURS UNCONTENDED, hpoing that one
day I will be allowed to use a shortcut analogously unbiased for nothing.

ciao
Alberto
Jul 23 '05 #7

P: n/a
In article <Ok**********************@news3.tin.it>, no****@nospam.nospam
enlightened us with...
It is a free forum,
EXACTLY.

I don't like rebuttals especially when made on style CUSTOMS (case in point,
precisely), and when I can I want to make a move to show how detrimental
they can be. Taking the initiative of the rebuttals is a practice that I
deem should start to be condemned.

Please learn the definition of rebuttal.
http://www.google.com/search?q=defin...oring=d&tab=gw

Rebuttals may or may not contain condescension, insults, and pejoratives. If
you don't like the way someone phrases something because it hurts your oh-so-
fragile ego, well, that's your problem. A lot of the times, people state
things in a way that might not be the most snuggly-wuggly to your ego, but
they still have a valid point.
If you feel like praising it so to encourage its spreading for you like it,
I respect your choice.
I praise rebuttals, open debate, and anything that eventually may lead to
better coding practices. As I said, learn the definition of the word please.
If you have a bone to pick about the way someone phrases something, that's a
different matter entirely than the fact that someone disagreed with you and
you feel that they insulted you or vilified you.

Yet you can tell a rebuttal from what you call "whether solutions are good
or bad" from the fact the rebuttal is clearly tailored and crafted not to
gently state a point but to vilify the other person, often with clearly ad
personam statements


It's Ad Hominem.
And that's called being an ass, not a rebuttal, and sometimes, it's the only
way to get things across to people.
You seem to be a case in point.

Have a nice day.
--
--
~kaeli~
When two egotists meet, it's an I for an I.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #8

P: n/a
Yours is a rebuttal: you use ironic statements like "please enlight us" -
you perhaps assume that the reason I am not going personal or sarcastic on
you as well is because you can't be dealt with in such a way. That's not
the case. The case is that I CHOOSE not to do that.
I am sad you can't find easy the same choice.
It's Ad Hominem.
it's ad personam too. That's latin, homo hominis is the term for "uomo",
persona personae is the term for "character". The latin preposition "ad"
takes in the accusative after it, which ends in "+am" in the case of the
latin first declination to which persona personae belongs to: so:
ad personam.

If you'd use homo hominis, that is the third latin declination whose
accusative ends in "+em": ad hominem.

Both mean the same thing, though you want to be enlightened and then you
argue about latin with an italian lol. And since both mean the same thing, a
proportion for you:

ad personam: ad hominem=
shortcut()? : if(){}else{}

So please if you take the time to correct off topic grammar issues, be sure
first you know the language you're making your correction about. I don't
deem you should speak ancient latin and that it would be a fault: I deem
that since you don't speak it and you can't be blamed for that, you also
should not correct things you don't know.

Yes I am having fun :-)

So:

Good example of positive intellectual contribution:
------------
var x=(y)?1:(y2?)?2:3;
I would like to suggest using the if-elsee statement blocks, I find nested
shortcut conditionals a bit harder to be read. They work, but I find them
less readable. I'd recommend the other for mere readability.
------------

Example of the same as a rebuttal:
------------
var x=(y)?1:(y2?)?2:3;
Gee what an absurd code, I can't tell you! OH MY GOD! You use it throughout
gee, and you can't even see HOW bad it is. I can't read it! You'd use
conditionals! THAT?s the way to do it!! Oh well, I am fed up with providing
you with my advice to fix your horrible codes.
------------

Can you sense the "slight" difference, and why PRECISELY for the sake of
that "learning" you mentioned we'd start condemning the latter, and
encouraging only the former practice?
And that's called being an ass, not a rebuttal, and
There you go, bad words. You took the initiative for them eh darling,
whereas all the time you argue YOU are enriching the "learning" environment
you were previosuly talking about LOL.
Didn't you mention to me the link to the FAQS ROFL ahahahahaha :)))))

What a teacher you are ahahahahah

Alberto
http://www.unitedscripters.com/

"kaeli" <ti******@NOSPAM.comcast.net> ha scritto nel messaggio
news:MP***********************@nntp.lucent.com... In article <Ok**********************@news3.tin.it>, no****@nospam.nospam
enlightened us with...
It is a free forum,
EXACTLY.

I don't like rebuttals especially when made on style CUSTOMS (case in point, precisely), and when I can I want to make a move to show how detrimental
they can be. Taking the initiative of the rebuttals is a practice that I
deem should start to be condemned.


Please learn the definition of rebuttal.

http://www.google.com/search?q=defin...oring=d&tab=gw
Rebuttals may or may not contain condescension, insults, and pejoratives. If you don't like the way someone phrases something because it hurts your oh-so- fragile ego, well, that's your problem. A lot of the times, people state
things in a way that might not be the most snuggly-wuggly to your ego, but
they still have a valid point.
If you feel like praising it so to encourage its spreading for you like it, I respect your choice.
I praise rebuttals, open debate, and anything that eventually may lead to
better coding practices. As I said, learn the definition of the word

please. If you have a bone to pick about the way someone phrases something, that's a different matter entirely than the fact that someone disagreed with you and you feel that they insulted you or vilified you.

Yet you can tell a rebuttal from what you call "whether solutions are good or bad" from the fact the rebuttal is clearly tailored and crafted not to gently state a point but to vilify the other person, often with clearly ad personam statements
It's Ad Hominem.
And that's called being an ass, not a rebuttal, and sometimes, it's the

only way to get things across to people.
You seem to be a case in point.

Have a nice day.
--
--
~kaeli~
When two egotists meet, it's an I for an I.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #9

P: n/a
Mmmmh what a Lady. You truly enrich the "learning" aspect of this group you
said you were so concerned about... LOL ahahahaha

I hope you wont' code as well as you speak, we risk "learning" far way too
much LOL ahahahahahahahah :-)

ciao
Alberto
And that's called being an ass, not a rebuttal, and sometimes, it's the only way to get things across to people.
You seem to be a case in point.

Have a nice day. ~kaeli~

Jul 23 '05 #10

P: n/a
On Wed, 18 Aug 2004 15:57:47 GMT, Alberto <no****@nospam.nospam> wrote:
Hallo Michael, happy you found the thread interesting though it seems
you miss my point: I am making a point against the habits of rebuttals:
I understood the point just fine.

[snip]
That's the point - even script-disabled browsers won't confuse the
contents of the script. The historical reason why the SGML comment
delimiters were used, was that browsers produced before the SCRIPT
element


I myself don't always use them, and yet there is a custom to use them. I
can't see why making of a custom that has been our legacy for 10 years
should be turned into a reason to stress it as a "bug" which needs a
"fix": ours, needless to say.


Not a bug, just pointless. Why do something that serves no purpose?

If I remember correctly, it *must* be avoided in XHTML. In that case, the
user agent will completely ignore the script.
has been the minimum allowed for a SCRIPT element for almost seven full
years. Your argument that it is relatively recent is therefore wrong,
plain and simple.


See perhaps it is because I am italian and we have an habit to be
gentlemen,


Is that supposed to be an attack?

You stressed that the type attribute was recent and that only "purists"
use it. I was asserting that you were wrong. It wasn't an insult, just a
statement of fact.

[snip]
I don't see what relevance that has to writing correct HTML.


It IS correct HTML. It doesn't mean to be XHTML.


The code that was quoted

<script language="JavaScript" src="../miscella.js">

and

<script>

is not valid HTML, nor is it valid XHTML.

The reason that valid HTML is stressed in this group is that letting a
browser use "quirks mode" can result in unpredictable script behaviour.
That, and it's about time that Web stops being polluted with badly written
HTML.

[snip]
If I see a commented out script tag, I don't argue it is "writing wrong
html" - browsers work fine with it, to me it is fine.
As I said above, that statement doesn't always hold true with scripts.
Besides, why should browsers have to deal with it? Browsers would be
smaller and faster if they didn't have to worry about error-correcting the
majority of pages on the Web.

[snip]
I'll put that down to English as a second language. He didn't say,
check to see IF characteristicIsHREF is a boolean, he said that you use
it AS a boolean.


To me that's fine. If a variable gets assigned 1, I can check
if(variableName)


You seem to be missing the point. For example,

if(obj) {

If obj is an object reference, it will evaluate to true and the if block
will be entered. What's the benefit of

var isTrue = obj ? true : false; // 1 : 0, whatever.
if(isTrue) {

If you know the language, as you claim, neither makes more sense than the
other, as they both involve basic concepts that are present in almost
every programming language.
I find it 100% ok, javascript is NOT Java, is not strongly data typed.
We're speaking of javascript.
I know several programming languages, Java being one of them. You don't
need to tell me that there is a difference: I know.
I can assign a valuje and check it as a boolean.
Languages do that all the time if(0) amounts to false as well as
if(false) amounts to false. So what?
But why convert a value that already evaluates as a boolean correctly to
an integer? If you must convert it, surely a boolean is more sensible.

[snip]
I would also like for instance to use things like:
!==
or
===
which I am aware of. Yet my personal habit is of preferring shortcut
conditionals.
What do the "strict equal/not equal" operators have to do with the
conditional operator?
Insisting on this personal preference while at the same time admitting
that both work, make little sense Mike.
I actually stated that none of it was necessary in the first place. That's
what I'm asserting.

[snip]
However, it only has an advantage if you will use that regular
expression often. According to the code above, the complied object will
be destroyed immediately after anyway, so it's a waste of time.


I have a conception of time on platforms running a pentium that doesn't
consider these aspects relevant.


So if time is irrelevant, why compile it in the first place?

[snip]
I'll also add another reason not to use it: whilst compile() might
exist in JavaScript, it doesn't exist in ECMAScript, the standardized
language. Calling the method may result in an error.


That is true, but my scrfipt tags carry written language=javascript, so
who runs ECMA won't bother. And now all those who run ECMA please raise
your hand lol :-)))


Umm, Opera, IE, and Mozilla, I believe. As I said, ECMAScript is
standardised JavaScript. Most modern scriptable do, or will, implement it.
They may choose to include proprietary JavaScript or JScript objects and
methods, and they may not. But, seeing as the compile call is unnecessary,
why risk breaking your scripts?

By the way, I don't think any modern browser actually honours the language
attribute. Most don't even care about the type attribute as they only
implement one scripting language. Just because you use that outmoded
attribute doesn't make you immune to the issue.
Don't be facetious.


No? I should cry? LOL :-)


*sigh*
No, the point is that the conditional operator can be extremely
confusing as it doesn't provide an means of clarity, unlike the braces
of an if statement.


As said, I don't care: it is clear to my eyes, and by the way since you
stressed speed (which I don't concern much about), it is faster. ANYWAY
IT IS my CHOICE, IT WORKS, IT IS implemented in all languages AND SO I
USE IT. Period.

Much ado about a legitimate use Mike.


Again, you ignore the context of my comment and resort to being petty.

My comment was from the point of view of providing instructional code. In
those cases, it is better to be understandable all, than writing for
yourself. As you have made clear, you aren't interested in doing that.
Fine. My remark didn't apply and there is no need to comment on it.

[snip]
If you write your codes with the delusional idea your codes are perfect,
[...]
Considering that I advocated commenting on the posts of others because I
make mistakes myself renders that comment absurd.
I am happy to tell you I have never been so conceited to deem them as
such bedfiore my own eyes. But I can't see why a shortcut ()?: must be
the occasion to repeatedly stress it whould not be used, and on occasion
for personal attacks.


And exactly where are these personal attacks you keep mentioning? Grant
was dramatic, but hardly insulting.
And what's your point?


And what's yours? You don't like shortcuts. Fine.


Where did I say that? I use shortcuts whenever it is appropriate to use
them. However, I consider clarity more important than squashing everything
on to one line.

[snip]
It'll just result in an error or some strange bugs in your code.


Browse all my page codes (which I KNOW you couldn't care less), test
them all in the TEST FORMS, and if after 120 pages you see ONE single
error SHOW UP in the status bar, I will agree with you.


That has nothing to do with what I posted. My point was that if the
variable contained a string, thereby resulting in a property instead of an
array element, prepending ++ will do nothing but cause an error.

If you want to show that the value is a number, why not use

anArray[ +variable ]

This should be clear enough without actually needing to subtract from the
result of the expression.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail
Jul 23 '05 #11

P: n/a
In article <qg**********************@news3.tin.it>, no****@nospam.nospam
enlightened us with...
Yours is a rebuttal: you use ironic statements like "please enlight us" -
you perhaps assume that the reason I am not going personal or sarcastic on
you as well is because you can't be dealt with in such a way. That's not
the case. The case is that I CHOOSE not to do that.
I am sad you can't find easy the same choice.


Oh, lord.
*plonk*

--
--
~kaeli~
Condoms should be used on every conceivable occasion.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #12

P: n/a
Ok Mike I got your points, you don't like shortcut conditionals, and the
comments after the script tags should be omitted because they are not
useful.

I understand that and I really think that by stressing them over and over
again we have given an incredible and outstanding contribute to improve
javascript syntaxes beyond imagination. Using or not using a shortcut rather
than an if else is a matter of outstanding importance.
Absolutely Mike, absolutely.
Not to mention that script comment tag issue which I now find of the
FOREMOST importance Mike, really the foremost importance oh absolutely Mike.
Really importantg, really.

---
use shortcuts whenever it is appropriate to use
them. However, I consider clarity more important than >squashing everything
on to one line.

---

and I now fully agree that an expression like
varx=!!!!!!varx
is much clearer an approach than
var varx=(!vary)?1:0;

Not that "squashing" has never been my intention, I simply find shrtcuts
would be easier for ME to understand than
!!var which implies we're even allowing:

if(!!!!!!!!!!!!!!!!!!!!!varx) varx= !!!!!!!!!!!!!!!!!!!!varx;

By the way do you find the above clear?
I find it remarkably clear now that I am letting in your suggestions. Do you
know what, that may even work. Try it ahahahahahahaha.

As a matter of fact I myself when I have to say that bewteen yellow and rose
I prefer yellow I never say:

"between yellow and rose I prefer rose"
but:
"between yellow and rose I prefer that which is not rose".

That adds much to clarity, I am now finally persuaded
Now that I have learned so many important, oh TRULY impotant things, I
dutifully thank you for the unremitting spring of relevant observations you
have made so insistentely always questioning my practice never one isntant
doubting yopurs, and bowing before your science that looks at the
FUNDAMENTALS of things and never gets carried away with futile details of no
importqance, I take my leave from you
please consider me your must faithful fellow subject and admirer,

Tristram Shandy, gentleman

ps sorry for typos, I won't fix them
Jul 23 '05 #13

P: n/a
How are your lessons in ancient latin going? LOL
"kaeli" <ti******@NOSPAM.comcast.net> ha scritto nel messaggio
news:MP************************@nntp.lucent.com...
In article <qg**********************@news3.tin.it>, no****@nospam.nospam
enlightened us with...
Yours is a rebuttal: you use ironic statements like "please enlight s" - you perhaps assume that the reason I am not going personal or sarcastic on you as well is because you can't be dealt with in such a way. That's not the case. The case is that I CHOOSE not to do that.
I am sad you can't find easy the same choice.


Oh, lord.
*plonk*

--
--
~kaeli~
Condoms should be used on every conceivable occasion.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #14

P: n/a
[Follow-ups set to alt.flame]

On Wed, 18 Aug 2004 16:21:56 GMT, Alberto <no****@nospam.nospam> wrote:
Mmmmh what a Lady. You truly enrich the "learning" aspect of this group
you said you were so concerned about... LOL ahahahaha
And you have the audacity to complain about being attacked?

Just so you're aware, kaeli wasn't calling you an ass but actually
agreeing that rude replies are the behaviour *of* an ass. A catagory to
which you now belong.
I hope you wont' code as well as you speak, we risk "learning" far way
too much LOL ahahahahahahahah :-)


Kaeli has helped a great many people and I'm glad she participates here.
I'm not too sure if I feel the same about you. Your behaviour is not the
way to earn the respect and patience of the regulars of this newsgroup,
nor is the way to act in a civilised, adult environment.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail
Jul 23 '05 #15

P: n/a
[Follow-ups set to alt.flame]

On Wed, 18 Aug 2004 19:04:18 GMT, Alberto <no****@nospam.nospam> wrote:

[childish nonsense]

If Opera had a kill file, you'd be in it.

Don't respond to this message. I won't be reading your reply.

I apologise to all other members of this group for dragging this farce on.
It was in the hope that I could communicate sensibly with the OP. It seems
I cannot.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail
Jul 23 '05 #16

P: n/a
Wow Michael, I am so happy that on this group there are persons like you who
read a bad word, repeat it, address it personally twice, and call all of
this the most important contribution to spreading the educational purposes
of a good javascript coding ahahahahahaha.
Isn't that ironic?

I am happy that I don't code like you. If coding like your guidelines
suggest, ends up calling folks an ass by your own personal initiative, I am
happy that I have not been educated yet by you (and your mom?) to consider
that practice as an educational practice.

I hope the beginners you say you care so much about here won't get the wrong
idea: learning javascript does not mean becoming like Mike. Only who is
ALREADY a Mike then becomes also like him.

ciao
ps the miscellaneous insults and terms of abuse I could have reciprocated
for you I won't add because of my PERSONAL choice, not because you won't
deserve them or becasue you could not be addressed the same way.
My choice.

PS nice crossposting Mike.

ciao
Alberto

And you have the audacity to complain about being attacked?

Just so you're aware, kaeli wasn't calling you an ass but actually
agreeing that rude replies are the behaviour *of* an ass. A catagory to
which you now belong.

Jul 23 '05 #17

P: n/a
yawn. As I said, thank you for your valuable comments.
From now on I will use
var x=!!!!!!!!!!!x

that adds to clarity A LOT INDEED I agree.

ciao
Jul 23 '05 #18

P: n/a
Alberto wrote:
Hallo Michael, happy you found the thread interesting though
it seems you miss my point: I am making a point against the
habits of rebuttals:
I think Michael understood your point fully. He was pointing out that
most of the points Grant raised were factually true, and those that are
opinion represent opinions that are common among programmes. Hardly
surprising as Grant is an experienced professional programmer who has
worked extensively with javascript.

What you elect to perceive as rebuttals might better be regarded as
peer-review by experienced colleagues. And that is a good thing as you
won't find yourself in many environments where anyone has time to
provide informed peer-review of your code on a daily basis. It is this
aspect of comp.lang.javascript that makes it such a good place to learn
javascript. The result may seem critical (even excessively critical, or
rude) but skills evolve quickest in a hostile environment (assuming that
participate in the exchange).

It is worth remembering that when someone posts to comp.lang.javascript
under their own name, knowing the group to be archived, they are
effectively putting their professional reputation on the line. So the
advice you get will be the best they are capable of giving.
########################quote
Good example of positive intellectual contribution:
------------
var x=(y)?1:(y2?)?2:3;
I would like to suggest using ... <snip> Example of the same as a rebuttal:
------------
var x=(y)?1:(y2?)?2:3;
Gee what an absurd code, ... <snip>
Can you sense the "slight" difference, and why PRECISELY for
the sake of that "learning" you mentioned we'd start condemning
the latter, and encouraging only the former practice?
Instruction tends to be most effective when it is accompanied by
explanation. Beyond that the exact tone is not too important. The
diverse linguistic backgrounds of contributors to the group means that
sometimes subtlety is lost in translation. A response may seem
aggressive or patronising for not reason but that, or it may be
intended.

Verbal aggression is often the response to individuals who disregard (or
worse, argue against them) the posting conventions of the group (as laid
out in the FAQ). That mostly represents an attempt to get them to go
elsewhere, and is justified because disregard for those conventions has
the effect of wasting the (precious) time of the other participants in
the group.

There is also a "right of passage" aspect to an initially excessively
critical and apparently hostile response to posted code. The group can
be critical so it is probably a good idea if individuals who decide they
want to join in are met with all guns blazing. To see how they react,
those that come back fighting (in the sense of posting corrected code,
or backing there position up with reasoned argument, and engaging in the
debate on the validity of those arguments) invariably turn out to be the
individuals for whom it is worth putting some effort in, as they will be
willing to learn.

There is quite a strong tendency for individuals who have experienced
minor some success with javascript, DHTML, DOM scripting, etc, and how
start posting to the group to have that exaggerated perception of their
own skills that follows from having not been exposed to the bigger
picture. That was certainly true of me when I started posting to the
group. A little deflating of the ego with some critical code analysis,
and pointing out of the unseen issues, is virtually a pre-requisite for
gaining the skills to actually tackle the problems and issues of
cross-browser Internet scripting.

Finally there is one last, and inevitable, human reason for seemingly
hostile posts, and that is the mood of the individual at the time. If
you have spent the day dealing with the consequences of other peoples
badly authored code in a context where you couldn't express the
resulting frustration, for example, then that frustration might end up
being expressed in response to the next example of poor code
encountered. But circumstances change, and moods change. People have
good days and bad days (and lots of variety in between).

<snip>
That's the point - even script-disabled browsers won't
confuse the contents of the script. The historical reason
why the SGML comment delimiters were used, was that browsers
produced before the SCRIPT element


I myself don't always use them, and yet there is a custom to use
them. I can't see why making of a custom that has been our
legacy for 10 years should be turned into a reason to stress
it as a "bug" which needs a "fix": ours, needless to say.


Grant didn't say they were a bug, he said "not needed and not
recommended", which is true. Michael has explained why they are not
needed, and in sceptre that is to be downloaded for interpretation on
the client anything that is totally superfluous is usually not
recommended. Historical precedent, or tradition, is in itself hardly a
justification for any practice in computer programming.

<snip>
I don't see what relevance that has to writing correct HTML.


It IS correct HTML.


By what criteria? Valid HTML is objectively determinable. and omitting
the required TYPE attribute does not result in valid HTML 4.
It doesn't mean to be XHTML. I am flexible enough to
understand that if a page of 100 kb has a wrong closing tag
or a comment tag in a script, that is DEFINITELY nothing
to blast a page for.
In the HTML groups, calls for reasons for using valid HTML don't tend to
get very convincing responses because web browsers can usually cope with
anything you throw at them (in the sense of displaying it and usually
providing a reasonably consistent prevention through CSS styling). But
scripting an HTML DOM is another matter entirely. There have been many
questions asked on the group about nightmares in cross-browser
compatibility and unexpected behaviour in individual browsers, that have
been directly attributed to the fact that the original HTML was not
strictly valid. The bottom line is that valid HTML produces structurally
consistent HTML DOMs and structurally consistent HTML DOMs are
infinitely easier to script than the almost randomly structured DOMs
that are generated from invalid HTML. When scripting HTML the validity
of that HTML makes a difference, and you cannot verify that the HTML is
formally valid if you don't use valid SCRIPT tags.
I am surprised I seem to be the onlyh one in this discussion
with this BAANAL MENTAL FLEXIBILITY.
You haven't seen the issue yet. If you take the advice now you maybe
never will.

<snip> To me that's fine. If a variable gets assigned 1, I can check
if(variableName)
I find it 100% ok, javascript is NOT Java, is not strongly data
typed. We're speaking of javascript. I can assign a valuje and check
it as a boolean. Languages do that all the time if(0) amounts to
false as well as if(false) amounts to false. So what?
In C, for example, the boolean values true and false are merely
alternative names for values that are actually numeric. In javascript
there is a boolean type. If a value is used on a context that requires a
boolean value and the expression evaluated to a non-boolean type then
automatic type-conversion happens. But when a value can be assigned as a
boolean value it does not need type-converting when used in a boolean
context, while a numeric value assigned will need type-converting on
each use. It is a simple matter of efficient coding.

<snip> ... . YET I use mine, which works as well, and
which produces no errors as well, and I STILL find to MY
EYES clearer a ()?: set than a !!var set.
It does not work "as well". In context, the double NOT operation is
considerably faster than the conditional operation, and also avoids much
subsequent type-converting.

<snip>
No, the point is that the conditional operator can be
extremely confusing as it doesn't provide an means
of clarity, unlike the braces of an if statement.


As said, I don't care: it is clear to my eyes, and by
the way since you stressed speed (which I don't concern
much about), it is faster.


No it is not faster. Speed testing the two in comparison suggest that
they are nearly equivalent with one or other having a very slight edge
on different browsers, but nothing that would allow one to be chosen
over the other on grounds of speed.
<snip>
How? The length property is a number, thereby always
resulting in an array.


No Mike! Negative. I want to make clear in my scripts
when I am updating an array and when populating an object.
It makes easier for me to revise them if necessary.
Also, atv times I have to make plurimous assignement to
more arfrays, and I update the index valuenonly once if
some condtions meet

loop
bla bla
if(x){L=++lastArray.length-1;
lastArray[L]=x
firstArray[L]=x;
};
end loop

Thence I gvot the habit, and I use it throughout - for a
fundamental (NOT total) consistency of coding is blamed
onto me lol

They are at times 500 lines of codes mike... I want to
safely discrimninate when it's an array or an object
which I am populating

<snip>

This whole notion is utterly misguided. Apart from the excessively
inefficient increment and subtract operation (which might be simplified
to the subtraction of zero alone, or unary plus alone), ECMAScript makes
no distinction between a bracket notation property accessor used for the
named property of an object and used for an indexed property of an
Array. Whatever expression is used within the brackets will be converted
to a string during the evaluation of the property accessor, the
difference between arrays and objects is that the internal [[Get]] and
[[Put]] method of an array will try to convert the string property name
into a number and treat it as a numeric index when that is possible.

Richard.
Jul 23 '05 #19

P: n/a
ciao Richard it is a pleasure to speak with you.
Please note that I am not anonymous: I not only put my website link on my
own comments, but I put my face too:

http://www.unitedscripters.com/list.html

scroll to the bottom Richard, and AT LEAST acknowledge me some intellectual
honesty. I dislike being depicted like the bad guy of the pack when all I
do is offer free codes. One doesn't like them? One doesn't get them. Does
one like them, I don't charge a penny.

But Richard: like anyone else doing this sort of work, I want to be
respected, do you understand?

I do not contend the professionalism of the others: but I expect them never
to attack mine, not the same as constrfuctive criticising, because I prefer
varx=(varx)?false:true;
to
varx=!!varx

Do you get my point Richard?
It is impossible to regard as positive intellectual contributions those
where your code is said "what an awful bunch" and where you get called an
ASS - without reicprocating
javascript. The result may seem critical (even excessively critical, or
rude) but skills evolve quickest in a hostile environment (assuming that
participate in the exchange).
Well done point Richard.

Well Richard, may I ask to you a favour you don't owe me? Would you devote 2
minutes of your time to GLANCE at this:
http://www.unitedscripters.com/writings/reviews1.html

You will see there how I speak of a clearly badly designed file: you will
see then how I speak with praise about the good things, not trying to
bolster my alleged low self esteem viewing the code and SCRAMBLING for a
personal preference I may finally have contended.

Pay me the respect I pay to those who don't attack me gratuitously, and I
may end up saying even thank you.
Attack me and call me ass because I prefer
varx=(varx)?1:0;
to
varx=!!varx

and you're (not you Richard lol) going to have troubles with me.
It is worth remembering that when someone posts to comp.lang.javascript
under their own name, knowing the group to be archived, they are
effectively putting their professional reputation on the line. So the
As I said, I do so, I also put my face in my posts, fearlessly.
explanation. Beyond that the exact tone is not too >important.
well "ass" repeated twice is not a tone LOL. But you're intelligent enough
to agree 101% it is not my personal sensitiveness
diverse linguistic backgrounds of contributors to the group means that
sometimes subtlety is lost in translation. A response may seem
aggressive or patronising for not reason but that, or it may be
intended.
True; "ass" doesn't belong there. It is not a thing that gets lost in
translation: it is exactly the thing that gets transmitted with or without
translations.
group. A little deflating of the ego with some critical code analysis,
and pointing out of the unseen issues, is virtually a pre-requisite for
gaining the skills to actually tackle the problems and issues of
cross-browser Internet scripting.
Richard, please: I sell nothing. Make a search on the internet after my
name:
Alberto Vallini

No secrets.
if I seem to you to be a person who doesn't care, whistle. One thing about
the ego is a super-ego, another thing is the ego of one who des NOT accept
being called ass and asshole and "awful code" simply on a STYLE custom
preference.

Richard, taking sides attacking me is not doing harm to me: is doing harm to
those that, only beacues more familiar to you, are more entitled to your
valuable respect, and counting on this they indulge in every bad word
practice possible.
Finally there is one last, and inevitable, human reason for seemingly
hostile posts, and that is the mood of the individual at the time. If
you have spent the day dealing with the consequences of other peoples
badly authored code in a context where you couldn't express the
resulting frustration, for example, then that frustration might end up
being expressed in response to the next example of poor code
encountered. But circumstances change, and moods change. People have
good days and bad days (and lots of variety in between).
Richard, listen to me: VERY TRUE.
What should have I done, said that you're saying bullshit when you're not?
You just said a VERY true thing. My ego is not such that I must now attack
you because you disagree: on the contrary I am ackowledging your point. Many
don't do this. We see this here.
Grant didn't say they were a bug, he said "not needed and not
recommended", which is true. Michael has explained why they are not


Richard, when they go to speak of "ass", they are ALREADY beyond the
courtesy boundaries you're so kind to ascribe to them here.

Let me use expressions like
++lenght-1
They work, I use them, I am expecting not to be called an ass just because
others would prefer an array incrementation which is less obvious in its
formal appearance.

You make more sense than all the previousn posts bundled toghether

ciao
Alberto
http://www.unitedscripters.com/

Jul 23 '05 #20

P: n/a
"Alberto" <no****@nospam.nospam> wrote in message news:28**********************@news3.tin.it...
An OUTSTANDING example of a rebuttal. Worth a glance. Rather long,
OBVIOUSLY feel fee to dismiss it entirely if not interested.

But this habit of the rebuttals must go to a stop (forgive odd english,
which is NOT my native tongue), if you consider what TYPE of rebuttals we
often see here.

I am truly still impressed that persons here STILL make rebuttals and don't
know the simplest courtesy guidelines.

My own: an user asks for a question, I get in if I can, answer HIS/HER
question with MY personal suggestion, and I do NEVER meddle with the others
who are kind enough to respond to him/her.
If I see an answer with a wrong code, I don't jump on that, I JUST state MY
OWN answer and I don't even metnion the answers of the others I found
uncorrect or questionable. I STICK to this rule. N_O R_E_B_U_T_T_A_L_S ..
EVER!

Of course, I answer when others don't follow these simple courtesy norms and
use online groups only as occasions to find ways to bolster their evidently
shaky self esteem by attacking the codes of the others EVEN if NO error is
in them.

As for the following, see what ABSURD observations: not one single mistake
in the code, yet this person is able to issue a whole rebuttal ALL focused
on STYLE CODING PREFERENCES - like "oh god! don't add brackets after
typeof" - go imagine....

I am really annoyed by this habit of the rebuttals.

Excerpts enclosed by ######### are quotations. Within them lines starting
with the > are my "offending" code that needed to be bashed so much oh so
much, and see WHY...

from:
http://www.forum4designers.com/archi...4-5-77131.html
---------------


#########
<script language="JavaScript" src="../miscella.js">

<script type="text/javascript" src="..."></script>
</script>
<script><!--

<!-- not needed and not recommended.
#########

For a few among us it is customary to add them. You know, that thing of a
browser with js disabled ya know.... You know yes...?

The type="text/javascript" is a RELATIVELY recent recommandation that a
purist may follow, but it adds or subtracts nothing to the functionalities.
The scripts work, details of the script tag interest me a bit less,
especially after I have made a 120kb long page of codes documentation -
which is ALL for FREE.


#########
function findSheet(characteristic, characteristicIsHREF){
if(!document.getElementById || !document.styleSheets.length){ return
false; };

Code blocks do not require trailing semi-colons. This mistake is repeated
throughout the code.
#########

Irrelevant rebuttal, I use them for MY own purpose: when a curly bracket
ends with a semi-colon, it means to MY EYES it is not the closing bracket of
a for or while loop but the end of a conditional statements set.

As long as you write functions that are 4 lines long you may not need
private conventions to spot them aside from indentation, as soon as you do
you may enforce a few of your own CONVENTIONS - which are not detrimental
in the least to the functionalities.
Irrelevant comment and rebuttal that didn't figure out there could be a
UTILITY for the coder.


#########
typeof is an operator, not a function. This can be made much more clear by
elminating the brackets from the operand: "typeof characteristic". This
mistake
it repeated throughout the code.
#########

typeof is an operator, and YET it is clearer to my eyes to add brackets
whenever possible, for instance i never do things like
if(some)varx=vary;
I always add brackets
if(some){varx=vary}
The same line of reasoning you adopt for the above rebuttal you can adopt
also to rebut that other habit of mine. I USE PARENTHESIS EXTENSIVELY. My
choice.

You're making rebuttals on unsubstantial points criticizing the personal
habits of another javascripter. That typeof is not a function we all know:
is a conceited assumption by you assuming that since I added brackets I
would have meant I thought it was.
Irrelevant comment, molreover based on wrong presumptions.


#########
this.characteristicIsHREF = (characteristicIsHREF)?1:0;

Why use 1 and 0 when you test characteristicIsHREF as a boolean later?
#########

I don't check anywere later to see if it is a boolean. Review better the
codes. You're arguing a non existant point here.

#########
var reg=new RegExp();
reg.compile("\\b"+arg2+"\\b","g");
return reg.test(arg1);

You don't need to construct a new RegExp() object, then compile it, then
test
it, you can do it all in a single operation:
return (new RegExp("\\b"+arg2+"\\b","g")).test(arg1);
#########

"There is more than one way to do it" - mine is not the better, yours is not
the better. They are just ways.
Irrelevant punctilious comment. The compile method EXISTS TO BE USED in
javascript, SO I CHOOSE TO USE IT. Period.

#########
else{
return(arg1==arg2)?true:false;

You're using a conditional to return the boolean result of an expression
that
returns a boolean:
return (arg1 == arg2);
#########

True, but so what? Can't I code with half a line more if it is clearer to my
eyes? what's the real difference, 10bytes more? Strange that you don't argue
here too that return "is not a function" LOL :-)))

#########
return (typeof(objectToReturn)=="undefined")?
false:new Array(
objectToReturn,
i,
objectToReturn.href.substring( objectToReturn.href.lastIndexOf("/")+1 ),
objectToReturn.href
);

What an ugly incomprehensible conditional. If you're going to include
unneeded
semi-colons at the end of code blocks, and use unneeded brackets on the
typeof
operator, why not use a few more characters to make it clear what you're
doing?
if (typeof objectToReturn == "undefined") {
return false;
} else {
return [
objectToReturn,
i,
objectToReturn.href.substring(objectToReturn.href. lastIndexOf("/") + 1),
objectToReturn.href
];
}
#########

Here you are objecting against the VERY SAME PRACTICE YOU YOURSELF
recommended earlier. In other terms, damned if you do damned if you dont
ahahahaahaha.
I don't recommend one practice, and I use both as I find fit.
Irrelevant and contradictory rebuttal. You first argue for a shortcut
return(z==y), then you complain about another shortcut.

#########
optionalIndex=(!optionalIndex)?1:
(obj.rules)?
obj.rules.length : obj.cssRules.length;

Nested conditionals? Lovely. Could you write code that is more difficult to
maintain?
#########

I use them extensively and I REGRET that PHP doesn't allow nesting them. The
fact YOU can't maintain THAT code or find it difficult to maintain it
doesn't imply others have your same limitations. I can maintain that better
with nested conditional shortcuts, and since it is ME and NOT you who has to
maintain them, I follow the functional guideline that I find ft to me and
not to you.

Irrelevant comment on personal tastes or intellectual limitations: you have
yours I have mine, and I maintain my own codes as I MYSELF find them easier
to maintain. I have to maintain them, NOT you, so stick to YOUR business and
maintain YOURS.

#########
off=(!off)?true:false;

Excuse me?
off = !off;
#########

Nope. In my scripts often I allow for arguments being passed also in data
type formats which are not the expected ones. Javascript is not java,
incoming arguments could be other data type than the expected one. I use
those statements to reconvert types to an expected format in case something
incoming goes awry.
You find
off = !off;
clearer
I find
off=(!off)?true:false;
clearer.

You keep contending all the while with the rules of maintenance clarity that
YOU find better. I don't contend yours, but none of your points make a
point: both expressions are equally valid, yourn personal taste has no
technical relevance and your comment is once again an irrelevant rebuttal of
NO practical substance.

#########
obj.disabled=(off)?false:true;

obj.disabled = !off;
#########

Same as above. YOU keep arguing that YOUR syntax is clearer. I don't find it
clearer. You want to use it? use it and don't bother others who have
personal preferences that do not meet your coding HABITS.

#########
indexOrObject=(indexOrObject && !isNaN(parseFloat(indexOrObject)))?
parseFloat(indexOrObject):
(typeof(indexOrObject)=="object")?indexOrObject:0;

Wonderful, more incomprehensible nested conditionals. Not only are they hard
to
read, you're doing way more method calls and tests then are required:
var indexOrObjectFloat = parseFloat(indexOrObject);
var indexOrObjectIsObject = (typeof indexOrObject == "object");
#########

AGAIN: I use EXTENSIVELY nested conditionals, I find them MORE readable and
the fact you prefer a swet of if/else to shortcuts doesn't affect in the
least the codes and what they do, and nmot even their speed as a matter of
fact.

Irrelevant gratuitous rebuttals still starting by the assumptions YOUR
pesonal preferences are THE guidelines. I never thought mine couold have
been, it seems for you it goes without discussion your would have been...
wow.

#########
var isObj=(typeof(indexOrObject)=="object")?1:0;

Again, assigning 1 or 0 based on an expression that returns a boolean to
what is
essentially a boolean flag.
var isObj = (typeof indexOrObject == 'object');
#########

Your opinion, disguised as a rule. You find your statement clearer, I don't
find it clearer and I use mine on MY scripts. So what? Your point is?
Notre I add the brackets to typeof, as you contended earlier. I find them
clearer. Again, PERSONAL opinions. You just vest them as rules, I don't do
that with mine.

#########
output[OL][2][ ++output[OL][2].length-1 ]=grab;
output[OL][3][ ++output[OL][3].length-1 ]=current;

Oh my god.
Isn't ++value - 1 == value?
so:
output[OL][2][ ++output[OL][2].length-1 ]=grab;
output[OL][3][ ++output[OL][3].length-1 ]=current;
is exactly the same as:
output[OL][2][output[OL][2].length]=grab;
output[OL][3][output[OL][3].length]=current;
#########

Not it isn't. Your codes could produce Objects not arrays. It is my habit,
when I increase an array, to make it clearer its NUMERICAL indexed key
nature, to discriminate it from an associative indexed object, by always
using ++. I find it clearer to my eyes, and it is 101% legitimate - a few
EVEN recommend it, go fancy...

Again, you argue on UNSUBSTANTIAL points, calling in even God to support
your position. But that's an hypothesis I don't need when I just deal with
javascript. I call in God's names for serious things ONLY.

#########
object=(!isNaN(parseFloat(object)))? parseFloat(object):object;

You're calling parseFloat() twice if object ends up being a number, and
you're
doing an unnecessary assignment if it's not.
#########

There is an alternative:
object=parseFloat(object)
then the conditional.

I prefer keeping all in a shortcut line, and calling twice a parseFloat
doesn't bother me, I am not interested in saving an half of an half of a
picosecond on a pentium 1200.

#########
I could go on, but I can't be bothered telling you how to fix your horrible
code
any longer.
#########

You have a conception of fixes that makes no sense. The code works, you call
AESTHETICAL requirements that follow YOUR own personal tastes a "fix" - you
fix bugs, not style preferences:
tupeof obje
and
typeof(obj)are not in a reciprocal relation of fix versus bug.

#########
Why are there 100 lines of inline Javascript on that page? You enjoy forcing
your users to download that much Javascript everytime they visit the page
it's
on?
#########

Because it is MY personal website, where I offer 120 files of an average
75Kb of documentation for FREE to wheoever may want it. So if one doesn't
weaqnt them, one doesn't get them, if one waqnts them, one gets them for
FREE. Others for 120 files of codes would have started asking money.
Probably your case.

Alberto Vallini, who codes as HE find fit on HIS OWN websikte, especially
when he gives all HIS codes for FREE.
http://www.unitedscripters.com/









Alberto a Man after my own heart. What you said is true and
really should be listened to by many here. I'd be damn
surprised if you didn't end up on many's ban list. That's the way the creeps here
think we are intimidated.

George Hester
Jul 23 '05 #21

P: n/a

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:cg*******************@news.demon.co.uk...
...points Grant raised were factually true, and those that are
opinion represent opinions that are common among programmes. Hardly
surprising as Grant is an experienced professional programmer who has
worked extensively with javascript.


It really matters little to me how much of a "professional" he is. One thing he is is irritating.
He's RIGHT always RIGHT never less than RIGHT so RIGHT just one fat RIGHT.
I wish he'd go find Miss RIGHT and they can just RIGHT RIGHT RIGHT RIGHT till the cows
come home.

GH
Jul 23 '05 #22

P: n/a
On Sat, 21 Aug 2004 16:20:40 GMT, George Hester <he********@hotmail.com>
wrote:

[snip]
Alberto a Man after my own heart. What you said is true and really
should be listened to by many here. I'd be damn surprised if you didn't
end up on many's ban list. That's the way the creeps here think we are
intimidated.


You quoted all of his post, just to say that?

No-one here is trying to intimidate anyone. Criticism is being given where
it is needed. Grant's comments were perfectly valid.

Usenet is an adult environment and, as an adult, you should be capable of
hearing, "Rubbish!" without resorting to whining.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #23

P: n/a
On Sat, 21 Aug 2004 16:37:13 GMT, George Hester wrote:
He's RIGHT always RIGHT never less than RIGHT so RIGHT just one fat RIGHT.


Yeah, It's great isn't it? Saves me a lot of time.

Thanks Grant!

[ Oh by the way Grant, I think you were actually
'wrong' once ..but since it was a minor typo. I
decided not to bother you with it. ]

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
Jul 23 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.