Topic: if self.isCoder(): post() #Programming Thread (Read 890169 times)

bloop_bleep · « **Reply #10785 on:** March 21, 2018, 02:56:17 pm »

Can't you just use arguments in the first method?

This works, for example (excuse the lack of indentation, I whipped this up quickly in notepad):

Code: [Select]

<html>
<head>
<script>
var test = function(a, b, c) {
    alert(a);
    alert(b);
    alert(c);
}

test("a", "b", "c");
</script>
</head>
<body>
blah
</body>
</html>

lethosor · « **Reply #10786 on:** March 21, 2018, 03:16:10 pm »

There is a difference. "function x" is parsed (at least partially) before "var x = function", so you can refer to x before it is defined using the former, but not the latter.

Telgin · « **Reply #10787 on:** March 21, 2018, 03:19:13 pm »

It can also make it more clear if you're redefining a function for some reason, but either way, both syntaxes work the same way as far as arguments and function invocations are concerned.

Mephisto · « **Reply #10788 on:** March 21, 2018, 03:53:21 pm »

Quote from: Parsely on March 21, 2018, 02:51:12 pm

But I'm not sure if there is some key difference between these methods that I don't understand, like, maybe hiding the function behind a variable instead of referencing it directly in the HTML is more secure?

That's not security. Both are available on the window object.

Code: [Select]

var foo = function() { console.log('foo') }
function bar() { console.log('bar') }

window.foo();
window.bar();

strainer · « **Reply #10789 on:** March 21, 2018, 05:47:43 pm »

`var x` gets "hoisted" which means it has the legal value of "undefined" until an expression sets its value in the order of execution. Its value can be assigned to anything (a number,string,boolean, function, object... ) any number of times within the var statements scope ( the containing object usually ).

`var x = function(){..}` is exactly the same as `var x; x=function(){...}`
And the `var x;`is part is "hoisted" to the beginning, the `x=fun..` part doesnt happen till it runs, and `x=other` can happen before.
Its easy to write `var i = something`and then some lines later write `var i = someother`the second `var` is just ignored, the same `i` gets
assigned to.

`function y()` is available before any order of execution.

Code: [Select]

console.log( "y() returns:", y() ) 
if (false){ function y(){return 1} } //never execs but function exists

console.log( "x is now:", x )  //is "undefined" not yet set
// console.log( "z is now:", z ) //this would break the script
if (true) { x=3 } // x happens to get set here
console.log( "x is now:", x ) //3
if (false){ var x=x||2 }  //x is hoisted by var regardless if true or false
console.log( "x is now:", x )
// outputs ...
y() returns:  1
x is now:  undefined
x is now:  3
x is now:  3

Beyond the differences in initialization I don't recall any practical differences in handling them, though there may be rare gotchas.
I prefer to use function x() and export as a property later if needed.

McTraveller · « **Reply #10790 on:** March 31, 2018, 05:16:16 pm »

Quote from: strainer on March 21, 2018, 05:47:43 pm

...though there may be rare gotchas.

There is no such thing as a 'rare' gotcha in javascript. They are all too common...

strainer · « **Reply #10791 on:** March 31, 2018, 05:53:26 pm »

As an oddball Ive grown to like it. Seems like a mashup of C and Lua, and Rust looks like javascript but Ive no idea if it is. Having a powerful debugger built into the major browsers is very handy.

McTraveller · « **Reply #10792 on:** March 31, 2018, 07:04:00 pm »

You can indeed do some nifty things in javascript that you can't in many other languages. Redefining functions after the fact is...nifty for testing purposes, for instance.

It's my belief though that it only succeeds in spite of itself. I'd also wager that if we didn't have those built-in debuggers, it would be effectively impossible to develop anything but trivial programs.

I mean seriously, just type the following into the console:

Code: [Select]

null == false
null > false
false > null
null >= false
false >= null

(I know why this happens, but it is still painful.)
EDIT:

Spoiler (click to show/hide)

EDIT 2: Yes, I know Python allows redefining functions too. It is a 'nifty' trick, but I count it as worse than pointers in terms of the nasty things it can produce. But as far as I know Python at least has internally consistent comparison operators.

bloop_bleep · « **Reply #10793 on:** March 31, 2018, 07:23:56 pm »

You can redefine functions in Python, actually, since almost everything there is a first-class object.

Code: [Select]

def a():
    return 1
print(a()) # prints 1
def a():
    return 2
print(a()) # prints 2

or:

Code: [Select]

def a():
    return 1
print(a()) # prints 1
def b():
    return 2
a = b
print(a()) # prints 2

strainer · « **Reply #10794 on:** March 31, 2018, 08:15:03 pm »

Those equalities - well I made quick guesses and only got two of them "right" No excuses because Ive read about them a few times, but in practice, I know to check comparisons like that when they could involve special values. Its not that hard maybe to work on safe terrain and know tiptoe through the rough. I find keeping on top of my own design chaos the hard work.

Quote

[JS] only succeeds in spite of itself.

I worry about the ECMAscript design committee since encountering one of their members on IRC teaching that arrays need very special declarations (never fully explained) or they will be treated as sparse and slow. I have done quite excessive amounts optimisation testing on the major engines and knew that what was being claimed was nonsense, impractical and even naive of how they work. But sure enough the dude was professional and on the committee.

I want everyone to use 'const' only on special occasions, but just know its going to end up a matter of respect and properness, like the explicit line-endings. 'let' had the potential to be so neat.

-ninja addon
Python has its benevolent dictator instead of a committe hasnt it?
There is endless syntactic magic getting added to javascript, quite useful mostly but daunting what we will end up with.
It looks like converting straightforward psuedocode into JS or Python is just a matter of 'dressing' the syntax for each, but JS makes it possible to write serious brainfuck in a mood.

bloop_bleep · « **Reply #10795 on:** March 31, 2018, 08:45:04 pm »

I disagree that it is less safe than pointers -- it is entirely intended and expected behavior, not some memory hacking trick. Functions in Python are equivalent to pretty much any other object; you can even create classes in Python that act like functions by defining the __call__ method. They can be assigned without any danger of memory invalidation, so the worst that can happen is that it throws an error when the function is changed to something else which is not compatible with the function calls in other parts of the code (different numbers of arguments for example); even then you get a message logged to the console instead of an outright segmentation fault like using pointers can cause.

It is nigh impossible to cause segmentation faults or other memory access problems in Python, except when there are such bugs in Python itself (which are so rare they almost don't bear talking about). This is very much intended design, and is part of the tradeoff with the performance penalties Python has when compared with other languages.

McTraveller · « **Reply #10796 on:** April 01, 2018, 07:01:56 am »

I wasn't referring to things like segfaults. I was referring to things like when you look at a piece of a code (for maintenance, review, etc.) and you can't reason about the code because of such features. Pointers suffer the same thing, of course, especially if you are using function pointers - you can't (always) tell at time of writing what the code is going to do*.

*Not limited to pointers or object modification, of course. There are many many ways to write code that is hard to reason about just by reading it.

bloop_bleep · « **Reply #10797 on:** April 01, 2018, 10:50:24 am »

I agree. Basically the only problem I can think of that requires using function redefinitions (that can't be solved by, e.g., passing the functions as arguments) is where you need to hack the functionality of some library or other module that you imported.

hops · « **Reply #10798 on:** April 12, 2018, 01:52:54 am »

Could someone explain the Dependency Inversion Principle for OOP to me? I mean, I'm probably just tired and I'd probably get one of the explanations for them after a short break, but might as well see if somebody could explain it better than the resources I'm relying on regarding:

Definition
Reason
How
Examples of violations and compliances

Rose · « **Reply #10799 on:** April 12, 2018, 02:08:13 am »

From what I understand of it from my brief reading, It's basically about using abstraction wherever possible.

Suppose you have a shopkeeper function, that sells peanuts, and you base it around selling peanuts. If you later want to use it to sell booze, you'll have to re-write it.

Instead, you start with the shopkeeper function, and decide what it needs out of any product type it needs to sell, presumable a way to check the price, and remove it from stock, and so on. Then you make the peanut class and the booze class both provide the product interface.

Bay 12 Games Forum

News:

Author Topic: if self.isCoder(): post() #Programming Thread (Read 890169 times)

bloop_bleep

Re: if self.isCoder(): post() #Programming Thread

lethosor

Re: if self.isCoder(): post() #Programming Thread

Telgin

Re: if self.isCoder(): post() #Programming Thread

Mephisto

Re: if self.isCoder(): post() #Programming Thread

strainer

Re: if self.isCoder(): post() #Programming Thread

McTraveller

Re: if self.isCoder(): post() #Programming Thread

strainer

Re: if self.isCoder(): post() #Programming Thread

McTraveller

Re: if self.isCoder(): post() #Programming Thread

bloop_bleep

Re: if self.isCoder(): post() #Programming Thread

strainer

Re: if self.isCoder(): post() #Programming Thread

bloop_bleep

Re: if self.isCoder(): post() #Programming Thread

McTraveller

Re: if self.isCoder(): post() #Programming Thread

bloop_bleep

Re: if self.isCoder(): post() #Programming Thread

hops

Re: if self.isCoder(): post() #Programming Thread

Rose

Re: if self.isCoder(): post() #Programming Thread