Web Analytics Made Easy -
StatCounter OOJS principles and good practice - CodingForum

Announcement

Collapse
No announcement yet.

OOJS principles and good practice

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    PROVE WHAT?!? PROVIDE WHAT?!? Information that's allready over this thread fifty ***ING TIMES OVER?!?

    I think what you're missing is I'm not arguing your examples that define scoping, I just fail to see their relevance when you might WANT to have something passed between scopes.

    Ok, lemme put it this way. What if you have something in your script1.js and your script2.js and they need to talk to each-other. How exactly would you accomplish that? Export... which puts something into the global scope so both can see it, defeating the point!

    At which point you've got ZERO improvement over anything IIFE provides. I'm ***ING DONE with you. WHAT ***ING CODE do you want that isn't already here, and WHAT about my argument are you failing to even grasp. DO YOU EVEN ***ING SPEAK ENGLISH?!?

    Actually... let's use MDN's example:
    https://developer.mozilla.org/en-US/.../Guide/Modules

    It's actually what soured me on the idea.

    If you need access to something from another module, you have to export it:

    export { name, draw, reportArea, reportPerimeter };

    Putting it into a separate namespace that could have conflicts. Hence the need to explicitly import it by script

    import { name, draw, reportArea, reportPerimeter } from './modules/square.js';

    Which could STILL conflict just as if it were global, so then you have to rename or assign them just as if they were globals resulting in ZERO damned improvement, or using "import" which means not using type="module". If you're just making a new space, one that's globally accessible via import, that can have all the same conflict woes, why the hell bother with any of this crap?

    You're just making more hoops to jump through that IIFE, normal classes, and all sorts of other mechanisms already provide. It's just changing the syntax and making everything harder to maintain. And why?

    Wah wah, teh globuls r teh evuls? They do actually exist for a reason, and if shoddy naming conventions, shoddy practices -- like the example you provided of it in the global space -- require all this extra "junk" then there is something horrifyingly WRONG with the codebases you're dealing with.

    I can't put it any plainer or simpler than that, and your constant "requests for code" THAT'S ALREADY IN THIS DAMNED THREAD simply means you don't understand enough English to be on an English language forum.

    Makes me think your solution to every coding problem is blind copypasta (probably why're you're crying 'wah wah code examples') and and problem-solving you do likely ends up akin to trying to patch up bullet holes in car tires with duck tape. It's the only reason you'd see value in any of this.

    Also no wonder you started kvetching about post lengths, the typical "wah wah TLDR" mouth-breather response I've come to expect in this age of the illiterate twitter-generation.










    I'll kill you and your dreams tonight, begin new life.
    Bleed your death upon me, let your bloodline feed my youth.
    https://cutcodedown.com

    Comment


    • #32
      I can't put it any plainer or simpler than that, and your constant "requests for code" THAT'S ALREADY IN THIS DAMNED THREAD simply means you don't understand enough English to be on an English language forum.
      You have made this claim several times: "modules are in global scope". I have shown you how this can be proven with an experiment that this is untrue and yet you are still claiming it is. I am asking you, through experiment, to demonstrate the truth of this statement.

      My "requests for code" are the only way to prove your point. Talk is hypothesis which can be tested with code. I know, you live in your own world you think the code runs differently but we can actually test those hypotheses with a few simple lines of code.

      Saying "Modules are in global scope" or "Modules are not in global scope" is not a statement of fact on its own, however much drivel you surround it with as it can be tested. I don't care if you write 80 pages telling me the world is flat, experimentation shows otherwise and your words are meaningless. The same is true here.

      edit: I asked you at least 3 times to demonstrate this with very clear step by step instructions on what I want you to provide and you have not because you don't understand the problem an IIFE actually solves. And no, it's not already in this thread.


      1. Provide an example where global scope causes a problem in a normal js script (not a module) (Remember, if you can wrap the whole file in an IIFE and the problem still exists, the problem is not an issue of global scope)

      2. Building on (1), provide a second example where you use an IIFE to fix that problem (this step is important as it demonstrates that the problem is solved by isolating scope)

      3. Provide a third example that replicates the problem from (1) using modules, thereby proving that modules are in global scope.


      The reason you need to do this is because you clearly do not understand the problem being solved in part 2 which is why you don't understand part 3. Until you understand the problem being solved the discussion is pointless.

      Putting it into a separate namespace that could have conflicts.
      Demonstrate this conflict happening with an example. WHY IS THIS SO HARD TO UNDERSTAND?!


      All you can do is say "It's already here" when I'm the only one who's posted examples! You clearly haven't tried the examples or don't understand them because they prove the opposite of what you are saying.


      You are, yet again, illustrating that you don't understand the basics well enough to even participate in this discussion.

      Here's, one other thought that might get us on the same page. Let's see what we agree on.

      Which of these statements do you agree with?

      1. We avoid polluting the global namespace as it causes problems with name clashes.

      2. It is possible to prove this problem exists via example code (if not, this problem does not really exist does it?)

      3. Code executed inside an IIFE is not in global scope.

      4. Not being able to create two variables with the same name in local scope (e.g. inside an IIFE) is not a problem of global scope because it happens in any scope.
      Last edited by Tom_B; Jun 9, 2020, 02:08 PM.

      Comment


      • #33
        edit: never mind, one step at a time.
        Last edited by Tom_B; Jun 9, 2020, 01:55 PM.

        Comment


        • #34
          edit: never mind, one step at a time.
          Last edited by Tom_B; Jun 9, 2020, 01:55 PM.

          Comment

          Working...
          X