|
I like the Haxe designer's approach to access control (not specific to const but moreso to class privacy):quote:You can access the private fields of a class or package by using @:access metadata. In fact, you can even use multiple @:access declarations in exactly the same way as @:allow.  glad to contribute nothing to the conversationfunny-internet-snipe.gif
|
#
?
Sep 27, 2013 02:27
|
|
|
|
| # ? Jun 11, 2024 07:00 |
|
|
I have zero faith that const helps the compiler catch actual mistakes. The C++ obsession with const correctness smells like Asperger's to me. Const is also a crutch that C++ programmers use to avoid thinking about mutation at design time, because anyone who wants immutability can just use const!
|
|
#
?
Sep 27, 2013 02:27
|
|
|
why is programming a gui in python such a pain in the rear end
|
|
#
?
Sep 27, 2013 02:29
|
|
|
FamDav posted:passing a reference by value is equivalent to passing a value by reference NO IT ISN'T, this was the central point of my previous posts. please read them again if you still believe this
|
|
#
?
Sep 27, 2013 02:29
|
|
|
Pollyanna posted:programming a gui in python
|
|
#
?
Sep 27, 2013 02:29
|
|
|
Pollyanna posted:why is programming a gui in python such a pain in the rear end just break down and use html as a poor man's gui toolkit
|
|
#
?
Sep 27, 2013 02:30
|
|
|
Mido posted:I like the Haxe designer's approach to access control (not specific to const but moreso to class privacy): Java has this also in the reflection API. It's even somewhat endorsed by the JCP--some JSRs specify that the library will reach into your objects and mess with private members. The reason it doesn't cause a problem, I think, is that the class indicates to the framework what the framework should do to the class's privates. It's when you start touching privates without an invitation that you have an issue.
|
|
#
?
Sep 27, 2013 02:31
|
|
|
Nomnom Cookie posted:Java has this also in the reflection API. It's even somewhat endorsed by the JCP--some JSRs specify that the library will reach into your objects and mess with private members. The reason it doesn't cause a problem, I think, is that the class indicates to the framework what the framework should do to the class's privates. It's when you start touching privates without an invitation that you have an issue. just like real life
|
|
#
?
Sep 27, 2013 02:33
|
|
|
Someone tell the Ruby programmers to stop touching privates without permission, their bad behavior is really getting out of hand.
|
|
#
?
Sep 27, 2013 02:33
|
|
|
Malcolm XML posted:just break down and use html as a poor man's gui toolkit i am seriously tempted to now. tkinter is better than this poo poo. at least it has documentation
|
|
#
?
Sep 27, 2013 02:35
|
|
|
Buy a Mac and use Cocoa, the only decent GUI toolkit.
|
|
#
?
Sep 27, 2013 02:37
|
|
|
Nomnom Cookie posted:Buy a pc and use wpf, the only decent GUI toolkit. shaggaring is easy
|
|
#
?
Sep 27, 2013 02:38
|
|
|
Nomnom Cookie posted:Buy a Mac and use Cocoa, the only decent GUI toolkit. i do in fact have a mac! and im considering just moving to objc (even if the syntax is balls)
|
|
#
?
Sep 27, 2013 02:42
|
|
|
Pollyanna posted:i do in fact have a mac!
|
|
#
?
Sep 27, 2013 02:43
|
|
|
Pollyanna posted:i do in fact have a mac! i dont know what you're up to but obj-c isn't bad and neither is like C#/xamarin stuff but you gotta pay to use the macos native widgets but you can use... gtk... actually don't go down this path just don't forget i ever said anything run from this place
|
|
#
?
Sep 27, 2013 02:44
|
|
|
JewKiller 3000 posted:NO IT ISN'T, this was the central point of my previous posts. please read them again if you still believe this in case another repetition helps: when you pass a reference by value, you have two copies of the reference, one on the caller's stack, and another on the callee's stack when you pass a value by reference, you have just one copy of the value, on the caller's stack. uses of the corresponding argument by the callee refer back to this single value on the caller's stack, and no copy is made. hence the name "pass by reference" if this doesn't matter for your use cases so you don't care, that's fine but you shouldn't go claiming that the two things are equivalent when the distinction between them can be very important especially since, as we have seen in this thread, there are a lot of people with incorrect understanding of evaluation strategies
|
|
#
?
Sep 27, 2013 02:47
|
|
|
JewKiller 3000 posted:1) yes but only in rare cases, and before you use it, think hard about whether you really need to and this is the absolute opposite of every language i can get paid to code in 
|
|
#
?
Sep 27, 2013 02:52
|
|
|
somehow they're still paying me to write my code in ocaml, a language that meets those criteria  oh right i know how, it's because nobody else at the company can even read my codebase much less modify it, and it does things that the business needs done. worksforme wontfix
|
|
#
?
Sep 27, 2013 02:55
|
|
|
JewKiller 3000 posted:NO IT ISN'T, this was the central point of my previous posts. please read them again if you still believe this eh, no, he's actually sort of right here. it's still not "pass-by-reference", but passing a pointer still means that you can mutate stuff "in" the previous function's scope. which can get messy in very obvious ways.
|
|
#
?
Sep 27, 2013 02:56
|
|
|
Mido posted:but you gotta pay to use the macos native widgets what Pollyanna fucked around with this message at 03:03 on Sep 27, 2013 |
|
#
?
Sep 27, 2013 02:57
|
|
|
Pollyanna posted:i do in fact have a mac! oooh, you are planning on tying yourself to a single-vendor ecosystem and reliving the cool 90's?
|
|
#
?
Sep 27, 2013 02:57
|
|
|
Nomnom Cookie posted:You're conflating reference mutation with value mutation. If the object is supposed to be immutable, then it will be written that way. If it's supposed to be mutable, then why the hell are you trying to make it immutable? Const StringBuilder is a ridiculous notion. i do know the difference between the two, i just think final should make not only the reference immutable, but the members of the object it refers to. as for why, sometimes it's nice to have some guarantees that this function, or this piece of code, or whatever, can't gently caress around with the state of this object.
|
|
#
?
Sep 27, 2013 02:58
|
|
|
Mido posted:I like the Haxe designer's approach to access control (not specific to const but moreso to class privacy): are you using haxe for anything currently? i've taken a look around and it seems neat esp for games and stuff (since it came out of flash) but there doesn't seem to be much of an ecosystem incase i hit a wall somewhere
|
|
#
?
Sep 27, 2013 02:58
|
|
|
PleasingFungus posted:eh, no, he's actually sort of right here. it's still not "pass-by-reference", but passing a pointer still means that you can mutate stuff "in" the previous function's scope. which can get messy in very obvious ways. that is absolutely true but refer to my latest repetition on what pass by reference means if an object is mutable and you give someone else a pointer to that object, they might mutate it through the pointer. this is definitely a serious issue, but it has NO BEARING on whether the pointer itself was passed by reference or by value, which is still an important distinction to make
|
|
#
?
Sep 27, 2013 02:59
|
|
|
Max Facetime posted:oooh, you are planning on tying yourself to a single-vendor ecosystem and reliving the cool 90's?  gently caress
|
|
#
?
Sep 27, 2013 03:03
|
|
|
Condiv posted:i do know the difference between the two, i just think final should make not only the reference immutable, but the members of the object it refers to. i agree, i wish const did this.
|
|
#
?
Sep 27, 2013 03:03
|
|
|
JewKiller 3000 posted:that is absolutely true but refer to my latest repetition on what pass by reference means he wasn't saying that passing a pointer by reference is the same as passing a pointer by value, though.
|
|
#
?
Sep 27, 2013 03:05
|
|
|
he literally said "passing a reference by value is equivalent to passing a value by reference", hence my objection i know it sounds like i'm sperging out about nothing here, but that equivalence statement is simply false
|
|
#
?
Sep 27, 2013 03:07
|
|
|
part of the issue is that we're using the word "reference" to refer to two different things: a pointer that is exposed at the language level, and a compiler-internal aliasing of one variable name to another
|
|
#
?
Sep 27, 2013 03:10
|
|
|
Pollyanna posted:
yeah I'm sure people will be frothing at the mouth on both windows and osx to use your babby first gui program
|
|
#
?
Sep 27, 2013 03:17
|
|
|
uG posted:yeah I'm sure people will be frothing at the mouth on both windows and osx to use your babby first gui program imma a be a gerat programer one day. ill be paid lots of money like $40000 dollars
|
|
#
?
Sep 27, 2013 03:21
|
|
|
wait what's wrong with mutability? why should i scrap an entire object and any children objects any time anything changes?
|
|
#
?
Sep 27, 2013 03:22
|
|
|
rust seems pretty cool but i dont want to use it (yet?)
|
|
#
?
Sep 27, 2013 03:24
|
|
|
Bloody posted:wait what's wrong with mutability? why should i scrap an entire object and any children objects any time anything changes? some day, which may never come to pass, people are going to do something weird like strap two CPUs together in a way that they share memory in the same process. or maybe in some distant future, people will work on codebases with an absurd number on lines of code, like 100,000. when that day comes, you will understand.
|
|
#
?
Sep 27, 2013 03:29
|
|
|
Bloody posted:wait what's wrong with mutability? why should i scrap an entire object and any children objects any time anything changes? mutability can be convenient, especially when working in imperative languages designed around assignment statements... but immutability is often desirable because it facilitates local reasoning (nobody can modify this object out from under me) and cooperates well with multithreading (you don't need locking to synchronize writes if you can't write at all) fortunately compilers are good at dealing with the potential issue you suggest. if you have a giant object and you just want to change one field, then conceptually, at the semantic level of your programs, you are making an entire copy of the object with the field equal to the new value. however, under the hood, the compiler can simply refer to the original object for everything except the new field, essentially keeping only a diff. this is safe because the object is immutable, so you know it can never change from its state when you created the "copy"! compilers for any language that takes pervasive immutability seriously will implement this optimization, to the extent that it is often MORE efficient to define an object as immutable if at all possible
|
|
#
?
Sep 27, 2013 03:31
|
|
|
JewKiller 3000 posted:in case another repetition helps: sorry, i should have clarified. for the purposes of knowing "if i put my X into this function it cant silently modify what i consider to be X", they are equivalent. X in this case being the object.
|
|
#
?
Sep 27, 2013 03:41
|
|
|
Brain Candy posted:some day, which may never come to pass, people are going to do something weird like strap two CPUs together in a way that they share memory in the same process. or maybe in some distant future, people will work on codebases with an absurd number on lines of code, like 100,000. as an embedded person these days will probably not come to pass.
|
|
#
?
Sep 27, 2013 03:42
|
|
|
FamDav posted:sorry, i should have clarified. that's true, and your point that the distinction between pass-by-value and pass-by-reference doesn't really address this issue of object mutability is well taken. in fact, i think we mostly agree; i'm only objecting to a misuse of evaluation strategy terms which, while sounding relevant to a discussion about the values of objects, are actually describing a language's strategy for resolving argument names
|
|
#
?
Sep 27, 2013 03:51
|
|
|
edited out some pointless exampleJewKiller 3000 posted:that's true, and your point that the distinction between pass-by-value and pass-by-reference doesn't really address this issue of object mutability is well taken. in fact, i think we mostly agree; i'm only objecting to a misuse of evaluation strategy terms which, while sounding relevant to a discussion about the values of objects, are actually describing a language's strategy for resolving argument names thats cool and im sure we agree. i just dont know why you keep bringing poo poo back to some programming languages 101 poo poo just because sulk doesnt know a thing. FamDav fucked around with this message at 03:56 on Sep 27, 2013 |
|
#
?
Sep 27, 2013 03:52
|
|
|
|
| # ? Jun 11, 2024 07:00 |
|
|
the reason i'm doing it is because sulk (others too) doesn't know a thing and this is the pl thread where we try to learn a thing
JewKiller 3000 fucked around with this message at 03:59 on Sep 27, 2013 |
|
#
?
Sep 27, 2013 03:56
|
|