Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #21053 > unrolled thread

Multiple image preload construct?

Back to article view | Back to comp.lang.javascript

Contents

  Multiple image preload construct? Tuxedo <tuxedo@mailinator.com> - 2013-08-27 16:32 +0200
    Re: Multiple image preload construct? Tuxedo <tuxedo@mailinator.com> - 2013-08-27 17:06 +0200
    Re: Multiple image preload construct? Danny <dann90038@gmail.com> - 2013-08-27 10:29 -0700
    Re: Multiple image preload construct? Ken <usenet-so@abdiassoftware.com> - 2013-08-27 13:32 -0500
      Re: Multiple image preload construct? Tuxedo <tuxedo@mailinator.com> - 2013-08-27 20:54 +0200
        Re: Multiple image preload construct? Ken <usenet-so@abdiassoftware.com> - 2013-08-27 18:19 -0500
          Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-28 01:37 +0200
            Re: Multiple image preload construct? Ken <usenet-so@abdiassoftware.com> - 2013-08-27 18:47 -0500
      Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-27 23:02 +0200
        Re: Multiple image preload construct? Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-08-27 23:20 +0200
          Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-28 01:27 +0200
            Re: Multiple image preload construct? Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-08-29 03:56 +0200
              Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-29 15:16 +0200
        Re: Multiple image preload construct? Ken <usenet-so@abdiassoftware.com> - 2013-08-27 18:43 -0500
          Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-28 02:08 +0200
            Re: Multiple image preload construct? Ken <usenet-so@abdiassoftware.com> - 2013-08-27 19:49 -0500
              Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-28 03:17 +0200
                Re: Multiple image preload construct? Ken <usenet-so@abdiassoftware.com> - 2013-08-27 20:35 -0500
                  Re: Multiple image preload construct? Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-08-29 19:32 +0100
                Re: Multiple image preload construct? John Harris <niam@jghnorth.org.uk.invalid> - 2013-08-28 16:20 +0100
              Re: Multiple image preload construct? Andrew Poulos <ap_prog@hotmail.com> - 2013-08-28 11:21 +1000
                Re: Multiple image preload construct? Ken <usenet-so@abdiassoftware.com> - 2013-08-27 20:48 -0500
                  Re: Multiple image preload construct? Andrew Poulos <ap_prog@hotmail.com> - 2013-08-28 13:43 +1000
                    Re: Multiple image preload construct? John Harris <niam@jghnorth.org.uk.invalid> - 2013-08-29 10:00 +0100
                      Re: Multiple image preload construct? Andrew Poulos <ap_prog@hotmail.com> - 2013-08-30 07:25 +1000
                        Re: Multiple image preload construct? John Harris <niam@jghnorth.org.uk.invalid> - 2013-08-30 10:11 +0100
          Re: Multiple image preload construct? Christoph Michael Becker <cmbecker69@arcor.de> - 2013-08-28 02:17 +0200
            Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-28 02:38 +0200
        Re: Multiple image preload construct? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-08-28 11:04 +0200
        Re: Multiple image preload construct? John Harris <niam@jghnorth.org.uk.invalid> - 2013-08-28 16:26 +0100

Page 1 of 2  [1] 2  Next page →

#21053 — Multiple image preload construct?

This runs a function after a single image has preloaded:

preload_img = new Image();

preload_img.onload = function(){
alert("done");
}

preload_img.src = 'image_1.jpg';

How can this be constructed in a simple way to run the function block after 
two images have preloaded? Eg. after:
preload_img.src = 'image_1.jpg' AND 'image_2.jpg';
... is complete?

Tixedo

[toc] | [next] | [standalone]

#21054

Tuxedo wrote:

> This runs a function after a single image has preloaded:
> 
> preload_img = new Image();
> 
> preload_img.onload = function(){
> alert("done");
> }
> 
> preload_img.src = 'image_1.jpg';
> 
> How can this be constructed in a simple way to run the function block
> after two images have preloaded? Eg. after:
> preload_img.src = 'image_1.jpg' AND 'image_2.jpg';
> ... is complete?
> 
> Tuxedo
> 
> 

The below works although I guess there can be better ways:

preload_img_1 = new Image();

preload_img_1.onload = function(){

preload_img_2.src = 'image_2.jpg';

}

preload_img_2 = new Image();

preload_img_2.onload = function(){

alert("done");

}

preload_img_1.src = 'image_1.jpg';

Tuxedo

[toc] | [prev] | [next] | [standalone]

#21055

To Tuxedo

I'd be better if you explain what is it you're trying to achieve.

[toc] | [prev] | [next] | [standalone]

#21056

On 27.08.2013 09:32, Tuxedo wrote:
> How can this be constructed in a simple way to run the function block after
> two images have preloaded? Eg. after:
> preload_img.src = 'image_1.jpg' AND 'image_2.jpg';
> .... is complete?

You need to keep track with a counter, for example:

     var images = ['img1url', 'img2url', 'img2url', ...];

     /// function to load all images in an array with urls
     function loadImages(imgs, callback) {

         var i = 0, img, count = imgs.length, result = [];

         /// create images
         for(; img = imgs[i]; i++) {
             var newImage = new Image();
             result.push(newImage);
             newImage.onload = handleLoad;
             newImage.src = img;
         }

         function handleLoad() {
             count--;
             if (count === 0) callback(result);
         }
     }

Now you can call the function:

     loadImages(myArray, loadDone);

     function loadDone(result)  {
         console.log('All images loaded!');
         /// result contains an array with the Image elements
     }

-- 
Ken Fyrstenberg
Abdias Software
http://abdiassoftware.com/
(remove usenet- from address)

[toc] | [prev] | [next] | [standalone]

#21057

Ken wrote:

> On 27.08.2013 09:32, Tuxedo wrote:
> > How can this be constructed in a simple way to run the function block
> > after two images have preloaded? Eg. after:
> > preload_img.src = 'image_1.jpg' AND 'image_2.jpg';
> > .... is complete?
> 
> You need to keep track with a counter, for example:
> 
>      var images = ['img1url', 'img2url', 'img2url', ...];
> 
>      /// function to load all images in an array with urls
>      function loadImages(imgs, callback) {
> 
>          var i = 0, img, count = imgs.length, result = [];
> 
>          /// create images
>          for(; img = imgs[i]; i++) {
>              var newImage = new Image();
>              result.push(newImage);
>              newImage.onload = handleLoad;
>              newImage.src = img;
>          }
> 
>          function handleLoad() {
>              count--;
>              if (count === 0) callback(result);
>          }
>      }
> 
> Now you can call the function:
> 
>      loadImages(myArray, loadDone);
> 
>      function loadDone(result)  {
>          console.log('All images loaded!');
>          /// result contains an array with the Image elements
>      }
> 

Many thanks for this great solution!

Tuxedo

[toc] | [prev] | [next] | [standalone]

#21062

On 27.08.2013 13:54, Tuxedo wrote:
> Many thanks for this great solution!

No problem mate.

Let me know if you get any problems. I wrote it inline so I didn't check 
everything.

To the other replies: It has been about 20 years since I last where on 
Usenet. I see not much has changed since then... :-]

-- 
Ken Fyrstenberg
Abdias Software
http://abdiassoftware.com/
(remove usenet- from address)

[toc] | [prev] | [next] | [standalone]

#21064

Ken wrote:

> On 27.08.2013 13:54, Tuxedo wrote:
>> Many thanks for this great solution!

Once again we can see here a beginner becoming the victim of overconfidence 
due to quick success, being unable yet to make a *proper* assessment of the 
code that they are using.  What was posted is actually _not_ a “great 
solution” by any reasonable measure.  The fact that the approach/code *can* 
work does not make it (a) “great” approach/code.
 
> No problem mate.
> 
> Let me know if you get any problems. I wrote it inline so I didn't check
> everything.

You wrote this code while being mostly clueless about the languages that you 
are employing, and you have presented it to your fellow beginner.
 
> To the other replies: It has been about 20 years since I last where on
> Usenet. I see not much has changed since then... :-]

You mean, that there are still *discussions*, that still nothing is taken 
for granted around here?  Indeed there are, indeed it is, and that is good 
so.  If you can't stand the heat, stay out of the kitchen.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21066

On 27.08.2013 18:37, Thomas 'PointedEars' Lahn wrote:
> If you can't stand the heat, stay out of the kitchen.

I have no problem with heat at all and I don't mind a *fruitful* 
debate/discussion which brings other than rants and pure opinion of 
flavors. Seems like you have stayed too much in the kitchen...

If you are unable to keep a fruitful discussion you will simply be ignored.

Have a nice day.

-- 
Ken Fyrstenberg
Abdias Software
http://abdiassoftware.com/
(remove usenet- from address)

[toc] | [prev] | [next] | [standalone]

#21059

Ken wrote:
^^^
Please fix, Ken #4711.

> On 27.08.2013 09:32, Tuxedo wrote:
>> How can this be constructed in a simple way to run the function block
>> after two images have preloaded? Eg. after:
>> preload_img.src = 'image_1.jpg' AND 'image_2.jpg';
>> .... is complete?
> 
> You need to keep track with a counter, for example:
> 
>      var images = ['img1url', 'img2url', 'img2url', ...];
> 
>      /// function to load all images in an array with urls

In these languages (not C#), documentation comments are better written
/*… */,  for “//” introduces single-line comments that are best used only 
for disabling code (and be used carefully on Usenet with its not fully 
defined line length).

>      function loadImages(imgs, callback) {
> 
>          var i = 0, img, count = imgs.length, result = [];
> 
>          /// create images
>          for(; img = imgs[i]; i++) {

That is awful code style for array iteration, in probably every language of 
the C family.  Consider this instead:

  for (var i = 0, count = len = imgs.length; i < len; ++i)
  {

>              var newImage = new Image();
>              result.push(newImage);
>              newImage.onload = handleLoad;
>              newImage.src = img;

It makes more sense to append the object reference to the Array *after* the 
object is prepared:

  var newImage = new Image();
  newImage.onload = handleLoad;
  newImage.src = img;
  result.push(newImage);

>          }
> 
>          function handleLoad() {
>              count--;
>              if (count === 0) callback(result);

Consider

  if (!--count)
  {
    callback(result);
  }

or

  if (--count === 0)
  {
    callback(result);
  }

You could also count upwards (naming the variable “loadCount”, for example).  
And you actually need only one Array, as ECMAScript Arrays are not typed by 
default:

  var img = new Image();
  …
  img.src = imgs[i];
  imgs[i] = img;

It is even questionable to have the Image instance references in an Array, 
as then there is no random access to them, for example by name or ID.

>          }
>      }
> 
> Now you can call the function:
> 
>      loadImages(myArray, loadDone);
> 
>      function loadDone(result)  {
>          console.log('All images loaded!');
>          /// result contains an array with the Image elements
>      }

Function expressions are widely supported by now, especially where 
console.log() is supported [1]:

  loadImages(myArray, function (result) {
    console.log('All images loaded!');
    /* result contains an array with the Image elements */
  });

[1] <http://PointedEars.de/es-matrix?filter=function>

Using your way is only necessary with event-handler properties, and probably 
only for *older* versions of JScript/IE (to work around the memory leak 
issue).

In your code you declare 3 global properties that should be avoided by using 
namespacing (for lack of a better word):

  var namespace = {
    …

    loadImages: function (/* … */) {
      // …
    }
  };

or, if necessary, by module pattern:

  var module = (function () {
    var _myPrivateVar;

    …

    return {
      …

      loadImages: function (/* … */) {
        // … access _myPrivateVar
      }
    };
  }());

See <http://PointeEars.de/scripts/test/hoverMe> for a better approach.  
(Although the image references are currently borken, the code should work.)

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21060

On 2013-08-27 23:02, Thomas 'PointedEars' Lahn wrote:
> Ken wrote:
[...]
>> Now you can call the function:
>>
>>       loadImages(myArray, loadDone);
>>
>>       function loadDone(result)  {
>>           console.log('All images loaded!');
>>           /// result contains an array with the Image elements
>>       }
>
> Function expressions are widely supported by now, especially where
> console.log() is supported [1]:
>
>    loadImages(myArray, function (result) {
>      console.log('All images loaded!');
>      /* result contains an array with the Image elements */
>    });

[...]

While function expressions support is fine now then passing as a 
parameter in the "loadImages" function with long code can make whole 
"loadImages" later harder to maintenance. It could be even worst if more 
parameters will be added to "loadImages".

But that's my opinion.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#21063

Cezary Tomczyk wrote:

> On 2013-08-27 23:02, Thomas 'PointedEars' Lahn wrote:
>> Ken wrote:
> [...]
>>> Now you can call the function:
>>>
>>>       loadImages(myArray, loadDone);
>>>
>>>       function loadDone(result)  {
>>>           console.log('All images loaded!');
>>>           /// result contains an array with the Image elements
>>>       }
>>
>> Function expressions are widely supported by now, especially where
>> console.log() is supported [1]:
>>
>>    loadImages(myArray, function (result) {
>>      console.log('All images loaded!');
>>      /* result contains an array with the Image elements */
>>    });
> 
> [...]
> 
> While function expressions support is fine now then passing as a
> parameter in the "loadImages" function with long code can make whole
> "loadImages" later harder to maintenance.

(_maintain_)  True.  OTOH, functions/methods should not be long.

> It could be even worst if more parameters will be added to "loadImages".
> 
> But that's my opinion.

I have been using the following code styles (in no particular order):

A)

  loadImages(myArray, function (result) {
    console.log('All images loaded!');
    /* result contains an array with the Image elements */
  });

B) 

  loadImages(myArray,
    function (result) {
      console.log('All images loaded!');
      /* result contains an array with the Image elements */
    });

C)

  loadImages(
    myArray,
    function (result) {
      console.log('All images loaded!');
      /* result contains an array with the Image elements */
    },
    foo);

D)

  loadImages(
    myArray,
    function (result) {
      console.log('All images loaded!');
      /* result contains an array with the Image elements */
    },
    foo
  );

But I can see how using a property reference can be of advantage.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21092

On 2013-08-28 01:27, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> On 2013-08-27 23:02, Thomas 'PointedEars' Lahn wrote:
>>> Ken wrote:
>> [...]
>>>> Now you can call the function:
>>>>
>>>>        loadImages(myArray, loadDone);
>>>>
>>>>        function loadDone(result)  {
>>>>            console.log('All images loaded!');
>>>>            /// result contains an array with the Image elements
>>>>        }
>>>
>>> Function expressions are widely supported by now, especially where
>>> console.log() is supported [1]:
>>>
>>>     loadImages(myArray, function (result) {
>>>       console.log('All images loaded!');
>>>       /* result contains an array with the Image elements */
>>>     });
>>
>> [...]
>>
>> While function expressions support is fine now then passing as a
>> parameter in the "loadImages" function with long code can make whole
>> "loadImages" later harder to maintenance.
>
> (_maintain_)  True.  OTOH, functions/methods should not be long.

Exactly what I meant. Regarding "_maintain_" - thanks.

>> It could be even worst if more parameters will be added to "loadImages".
>>
>> But that's my opinion.
>
> I have been using the following code styles (in no particular order):
>
> A)
>
>    loadImages(myArray, function (result) {
>      console.log('All images loaded!');
>      /* result contains an array with the Image elements */
>    });
>
> B)
>
>    loadImages(myArray,
>      function (result) {
>        console.log('All images loaded!');
>        /* result contains an array with the Image elements */
>      });
>
> C)
>
>    loadImages(
>      myArray,
>      function (result) {
>        console.log('All images loaded!');
>        /* result contains an array with the Image elements */
>      },
>      foo);
>
> D)
>
>    loadImages(
>      myArray,
>      function (result) {
>        console.log('All images loaded!');
>        /* result contains an array with the Image elements */
>      },
>      foo
>    );
>
> But I can see how using a property reference can be of advantage.

:-)

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#21096

Cezary Tomczyk wrote:

> On 2013-08-28 01:27, Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> On 2013-08-27 23:02, Thomas 'PointedEars' Lahn wrote:
>>>> Ken wrote:
>>> [...]
>>>>> Now you can call the function:
>>>>>
>>>>>        loadImages(myArray, loadDone);
>>>>>
>>>>>        function loadDone(result)  {
>>>>>            console.log('All images loaded!');
>>>>>            /// result contains an array with the Image elements
>>>>>        }
>>>>
>>>> Function expressions are widely supported by now, especially where
>>>> console.log() is supported [1]:
>>>>
>>>>     loadImages(myArray, function (result) {
>>>>       console.log('All images loaded!');
>>>>       /* result contains an array with the Image elements */
>>>>     });
>>>
>>> [...]
>>>
>>> While function expressions support is fine now then passing as a
>>> parameter in the "loadImages" function with long code can make whole
>>> "loadImages" later harder to maintenance.
>>
>> (_maintain_)  True.  OTOH, functions/methods should not be long.
> 
> Exactly what I meant.

I do not think so.  You have argued that using function expressions in 
function calls can pose a readability issue because functions can be long.  
I have argued that functions/methods should not be long in the first place 
(but larger pieces should be moved into separate functions/methods, which 
are then called in the original function/method).  So the problem you see is 
not supposed to exist in well-written code in the first place.

> Regarding "_maintain_" - thanks.

You're welcome.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21065

On 27.08.2013 16:02, Thomas 'PointedEars' Lahn wrote:
> That is awful code style for array iteration, in probably every language of
> the C family.  Consider this instead:

Oh, this is not C, this is ECMAScript in the JavaScript flavor, a 
dynamic language. Nothing is compiled, everything is interpreted. If you 
understand how interpreting works you would know this doesn't really 
matter (and in this case the bottleneck is not the loop).

> It makes more sense to append the object reference to the Array *after* the
> object is prepared:

Doesn't matter at all in this case. The Image element is a valid 
reference before src is set and image loading is an asynchrounous 
operation in JavaScript.

If its reference is kept in an array, object or as a variable does not 
matter at all as long as it is referenced.

Look at Image element as parent of data, not part of it.

> It is even questionable to have the Image instance references in an Array,
 > as then there is no random access to them, for example by name or ID.

I think you are forgetting that you can use the URL to identify which 
image has loaded if you need to reference its index.

> In your code you declare 3 global properties that should be avoided by using
> namespacing (for lack of a better word):

You are missing the point here. I am not providing a full working 
solution but an example. It's up to OP to modify and adopt to suit his 
needs.

 > Consider ...
 > You could also count upwards ...
 > Function expressions are widely supported by now ...
 > Using your way is only necessary with event-handler properties ...

I am not sure how any of this significantly improves anything (if at 
all), but thanks for your opinions.


-- 
Ken Fyrstenberg
Abdias Software
http://abdiassoftware.com/
(remove usenet- from address)

[toc] | [prev] | [next] | [standalone]

#21067

Ken wrote:

> On 27.08.2013 16:02, Thomas 'PointedEars' Lahn wrote:
>> That is awful code style for array iteration, in probably every language
>> of the C family.  Consider this instead:
> 
> Oh, this is not C,

ECMAScript implementations rather clearly belong to the C *family* of 
programming languages as opposed to, for example, Python.

> this is ECMAScript in the JavaScript flavor,

No, it is any ECMAScript implementation, depending on the runtime 
environment in which it is executed.  See also
<http://PointedEars.de/es-matrix> pp.

> a dynamic language. Nothing is compiled, everything is interpreted.

No, that is a common misconception.  Source code for ECMAScript 
implementations is either JIT-compiled to bytecode that is executed by a 
Virtual Machine, or it is compiled to platform-native machine code.  There 
is a tendency now to JIT-compile to platform-native machine code, as can be 
seen with Apple/WebKit JavaScriptCore SquirrelFish Extreme and Google V8 
JavaScript.

> If you understand how interpreting works you would know this doesn't
> really matter (and in this case the bottleneck is not the loop).

YMMD.

>> It makes more sense to append the object reference to the Array *after*
>> the object is prepared:
> 
> Doesn't matter at all in this case.

Yes, it does.

> The Image element is a valid reference before src is set and image loading
> is an asynchrounous operation in JavaScript.

Image loading is not even part of JavaScript (or ECMAScript), it is a DOM 
feature.  You must have been asleep for the last decade or so.

> If its reference is kept in an array, object or as a variable does not
> matter at all as long as it is referenced.
> 
> Look at Image element as parent of data, not part of it.

I am referring to how easy source code can be read and understood by a 
*person*.  It is harder to understand if it is written your way.  This 
matters of the target audience is a (one) beginner.
 
>> It is even questionable to have the Image instance references in an
>> Array, as then there is no random access to them, for example by name or
>> ID.
> 
> I think you are forgetting that you can use the URL to identify which
> image has loaded if you need to reference its index.

I think you do not understand how Arrays are working in ECMAScript, and what 
image preloading is used for in DOM scripting.  I also think you should 
refresh your knowledge on hash tables, which are likely used internally for 
property lookup (as opposed to linear array search).

>> In your code you declare 3 global properties that should be avoided by
>> using namespacing (for lack of a better word):
> 
> You are missing the point here. I am not providing a full working
> solution but an example. It's up to OP to modify and adopt to suit his
> needs.

Bad examples are *bad* examples.  You should post good examples, especially 
as followup to beginners.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21070

On 27.08.2013 19:08, Thomas 'PointedEars' Lahn wrote:
> Bad examples are *bad* examples.  You should post good examples, especially
> as followup to beginners.

That's still your opinion. The example works fine - what's easy to read 
is up to the eye of the beholder.

It seems as yo are assuming beginner is the same as "has no brain". If 
so I disagree.

And for the other claims, please provide some evidence and I will be 
happy to look at it.


-- 
Ken Fyrstenberg
Abdias Software
http://abdiassoftware.com/
(remove usenet- from address)

[toc] | [prev] | [next] | [standalone]

#21071

Ken wrote:

> On 27.08.2013 19:08, Thomas 'PointedEars' Lahn wrote:
>> Bad examples are *bad* examples.  You should post good examples,
>> especially as followup to beginners.
> 
> That's still your opinion. The example works fine - what's easy to read
> is up to the eye of the beholder.

There are rather objective criteria for what does and does not constitute 
good code style, even more so what constitutes an efficient algorithm and 
implementation thereof.  I find it hard to believe that in a C-style “for” 
statement an empty initialization part, and an unchecked array element 
access in the conditional part to iterate over an array would be considered 
good code style by anyone knowledgable.
 
> It seems as yo are assuming beginner is the same as "has no brain". If
> so I disagree.

Yes, that only seems to be so.  However, what does it tell you that this 
beginner calls your code “great” despite its obvious deficiencies and your 
*provably* actually not knowing what you are doing?  Could it not perhaps be 
that lack of the ability of proper judgement of work in a field is inherent 
to being new in a field?  Could it not perhaps be that bad code, bad 
examples, are not yet recognized as such without a hint; that they would 
otherwise be more likely to be not questioned, to be used verbatim from then 
on (due to lack of an alternative)?
 
> And for the other claims, please provide some evidence and I will be
> happy to look at it.

BTDT.  Do your own homework.

BTW: Address munging violates RFC 5536 and Netiquette.  Score adjusted.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#21073

On 27.08.2013 20:17, Thomas 'PointedEars' Lahn wrote:
> BTW: Address munging violates RFC 5536 and Netiquette.  Score adjusted.

Suit yourself caveman. Have a nice evening!

(PS: you seem to be in need of learning some etiquette from the *real* 
world..)

-- 
Ken Fyrstenberg
Abdias Software
http://abdiassoftware.com/
(remove usenet- from address)

[toc] | [prev] | [next] | [standalone]

#21111

In comp.lang.javascript message <kvjk83$ieb$1@speranza.aioe.org>, Tue,
27 Aug 2013 20:35:56, Ken <usenet-so@abdiassoftware.com> posted:

>On 27.08.2013 20:17, Thomas 'PointedEars' Lahn wrote:
>> BTW: Address munging violates RFC 5536 and Netiquette.  Score adjusted.
>
>Suit yourself caveman. Have a nice evening!
>
>(PS: you seem to be in need of learning some etiquette from the *real*
>world..)


I don't think he ever goes there.

-- 
 (c) John Stockton, Surrey, UK.  ¬@merlyn.demon.co.uk   Turnpike v6.05   MIME.

        <http://www.merlyn.demon.co.uk/quotings.htm#AWY> : AWY

[toc] | [prev] | [next] | [standalone]

#21079

On Wed, 28 Aug 2013 03:17:59 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Ken wrote:

  <snip>
>BTW: Address munging violates RFC 5536 and Netiquette.  Score adjusted.

They do not say that.

Besides, what makes you think it's munged ?

  John

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web