<JordanBrown>
So yes, you can say o=object(inc=function(v) v+1); and then you can say o.inc(123) and get 124.
<bitbasher>
that will do for a start surely?
<JordanBrown>
It's certainly a big improvement.
<JordanBrown>
But you cannot say o=object(val=5, f=function() val); and expect anything useful.
<bitbasher>
and .. if one defined a vector structure at the global scope methods on an object could be given its name to use .. work-around for this maybe?
<bitbasher>
a sort of hard coded this
<JordanBrown>
But if it's hard coded, there can only be one of it.
<JordanBrown>
There *is* a workaround. Function references drag along the context they were defined in, so you can say
<bitbasher>
but with object() as it is one can only have a single instantiation of a given object no?
<JordanBrown>
o = let(val=5) object(val=val, f=function() val);
<bitbasher>
oh yeah .. nasty gloop there .. but i get it
<JordanBrown>
and it will work, not because the function picks up the value from the object, but because it picks it up from the definition context.
<JordanBrown>
But as I think about it a bit more, that's not even worth thinking about as a workaround, because it drags that context around forever, even as the reference might be copied.
<bitbasher>
quiet popping sounds as parts of my brain implode
<JordanBrown>
So o2 = object(o, val=6) will get you a new object with o2.val=6, but the function was still defined in the original context and so *its* val is 5.
<JordanBrown>
Right. Forget everything I said starting "There *is* a workaround" :-)
<bitbasher>
right .. so, not a real workaround :)
<JordanBrown>
But it does let you have data structures that are much easier to understand than just using fixed indexes in vectors.
<bitbasher>
would an object get its own version of a Special Variable to play with ?
<JordanBrown>
the object per se does not affect scope at all. It's just a container for values.
<JordanBrown>
it's exactly equivalent to a vector.
<JordanBrown>
What you're really asking about is the behavior of function references.
<bitbasher>
umm .. okay but if an objects methods are referring to a special they get their own version of the special on their stack ??
<JordanBrown>
And special variables there behave exactly according to normal special-variables rules: step up the call stack until you find the variable.
<bitbasher>
yeah .. i want the getters and setters to work at a minimum
<JordanBrown>
If they are *referring* to it, no, they find the next instance of that variable up the call stack.
<JordanBrown>
If they *assign* it - which, for a function, means the expression-style let() - then they create a new variable that is visible to anything that they call (which, today, can only be functions).
<JordanBrown>
There can't be setters, because all OpenSCAD data objects are immutable.
<bitbasher>
right .. am i right in thinking that obj1=object( stuff=thing ) is not actually creating an object i can used to instantiatte with .. that in fact my obj1 is an instantaion
<JordanBrown>
maybe I should say 'data values", to avoid confusing the issue.
<JordanBrown>
It's related to the behavior in JavaScript.
<bitbasher>
javascript is another thing that makes my brain hurt
<JordanBrown>
It's a ton of fun to program in, but you can do seriously brain-bending things.
<JordanBrown>
Here and in JavaScript, there are objects but there are no classes.
<JordanBrown>
And there are no classes here because OpenSCAD does not have declarations.
<JordanBrown>
Er, does not have data declarations.
<bitbasher>
i love the thought of being able to assign anything to anything in javascript .. but the times i have had to get serious with it .. real hard going
<JordanBrown>
You mean that it's a horribly type-unsafe language?
<JordanBrown>
That's my least favorite aspect of it. Makes large-scale programs very hard to verify.
<bitbasher>
or .. alternately .. _every_ definition of a variable is its declaration
<bitbasher>
in scad i mean
<JordanBrown>
Yes, I suppose so.
<bitbasher>
still trying to get my head around the scad Way of Work
<JordanBrown>
Anyhow, if we get a "this" feature - probably the special variable $this - then you'd be able to create objects with methods.
<JordanBrown>
There would be no explicit inheritance, but if you say o2 = object(o1, a=123) you have created a copy of o1 with a=123, and that's a lot like inheritance.
<JordanBrown>
Yes, the OpenSCAD language is ... interesting.
<bitbasher>
but still .. o1=object( blah, blah ); and o2= object( other, stuff ) is making two unrelated objects yes?
<JordanBrown>
sure.
<JordanBrown>
It would be a duck-typed environment. You know that?
<bitbasher>
but does o3=object( o1 ); create a new instantiation in the sense of java or C++?
<JordanBrown>
if it walks like a duck and quacks like a duck, it's a duck.
<mwette>
openscad seems a lot more functional than imperative
<bitbasher>
oh .. sure, that sort of typing
<JordanBrown>
So you might have module box(params) { cube(params.size); }
<JordanBrown>
and that module would be happy with any params object that has a "size" member.
<bitbasher>
but in my o3= example .. i would get a clone of o1 and could not assign it new values right?
<JordanBrown>
You can never modify any OpenSCAD variable or data structure.
<JordanBrown>
They are always immutable.
<JordanBrown>
So yes, o3=object(o1) creates a copy of o1, but it's indistinguishable from o1.
<JordanBrown>
and because variables are immutable, it will always be indistinguishable from o1.
<JordanBrown>
just like v1=[1,2,3]; v2=v1;
<bitbasher>
humm .. we mioght what to think about NOT calling them objects then .. cause most folks with a background in procedural languages will misunderstand .. painfully so
<JordanBrown>
Or, for that matter, o3=o1.
<JordanBrown>
With respect to mutability, they are as much objects as OpenSCAD variables are... variables.
<bitbasher>
maybe term them structures with named elements ?
<JordanBrown>
OpenSCAD variables ... don't vary.
<bitbasher>
even .. static structures with named elements?
<JordanBrown>
One of the open-ish questions is what name to use. objects, dictionaries, structures, associative arrays, ...?
<JordanBrown>
But they are exactly analogous to OpenSCAD vectors.
<JordanBrown>
x = [1,2,3]; yields a constant vector; you cannot modify it.
<JordanBrown>
o = object(a=1, b=2, c=3); yields a constant object.
<JordanBrown>
But if we ever introduce methods, we definitely want to call them objects.
<JordanBrown>
It's entirely possible that r,g,b,a are not documented.
<bitbasher>
but then .. does object handle v2=object( v1, this=12, that="msg") so then cube( v2.this ) would be legal?
<JordanBrown>
of course, why wouldn't it?
califax has quit [Remote host closed the connection]
<JordanBrown>
While we're talking about the magic named members, to complete the set ranges have begin, step, and end.
califax has joined #openscad
<bitbasher>
because i would not expect object() to accept a vector as its first argument
<JordanBrown>
oh, sorry, no.
<JordanBrown>
well, depends on the form of the vector.
<bitbasher>
you mean r=[1:10] meanst that r.begin will work?
<JordanBrown>
Yes.
<JordanBrown>
One of the variations that object() accepts is a vector of two-element vectors, with the first being the name and the second being the value.
<bitbasher>
and what form of vector would object() accept do u thnk?
<JordanBrown>
Thus object(a=1, b=2) is equivalent to object([["a", 1], ["b", 2]])
<JordanBrown>
... which is a really awkward pattern, but allows for key-names that are expressions.
<bitbasher>
yeah .. that is a special use case for vector .. i was thinking to add named elements to a vector .. effectivly adding user defined element names to a vector
<JordanBrown>
Like I said, somebody suggested that a few years ago, but it made my head hurt, and I don't think I was the only one.
<bitbasher>
implementation could not be harder than the special case handling for v.x, v.r etc
<JordanBrown>
sure it could :-)
<JordanBrown>
But it was more the mental model than anything else.
<bitbasher>
so mate .. i need to get off to bed .. i will fix up the docs on speacials .. tomorrow
<JordanBrown>
Good night.
<bitbasher>
and to repeat .. any feed back on the docs would be Really Good to get .. please .. discussion pages or my talk page
<JordanBrown>
Do something about the "something general" entries on data types ASAP.
<JordanBrown>
I am not sure how I feel about having the headers there be links; that wasn't obvious to me.
<bitbasher>
oh right .. they are links to the concept pages not to the docs
<JordanBrown>
I don't know what the difference is between those two things.
<bitbasher>
i need to make a template to replace the brain dead def list notation that bold faces the links into invisibility
<JordanBrown>
But I will note that it is 17:43 for me and bedtime is not for a long time, so if you keep talking I'll keep talking and you'll never get to bed.
<bitbasher>
well .. the link on SVG goes to the wikipedia on the file format. the body of each definition will have the link to the page in scad docs
<bitbasher>
zzzzzzzzzzz
krushia has joined #openscad
Jerr80 has joined #openscad
Jerr8 has quit [Ping timeout: 260 seconds]
Jerr80 is now known as Jerr8
bitbasher has quit [Ping timeout: 276 seconds]
mwette has quit [Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.1)]
RichardPotthoff has quit [Ping timeout: 248 seconds]
teepee has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Ping timeout: 244 seconds]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
sculptor has joined #openscad
snaked has quit [Quit: Leaving]
TheAssassin has quit [Quit: No Ping reply in 180 seconds.]
TheAssassin has joined #openscad
bitbasher has joined #openscad
bitbasher has quit [Changing host]
bitbasher has joined #openscad
<bitbasher>
if there is anyone online who knows something about Special Variables and dynamic scoping could you look at my latest description of them to see if i am finally getting close to being correct about them?
<teepee>
getting closer I guess, it should probably be highlighted that they are not recommended for normal use
bitbasher has quit [Ping timeout: 260 seconds]
<InPhase>
I strongly disagree with listing this as a key advantage, "greater flexibility as variables may be accessed from any part of the program."
<InPhase>
It should really just be emphasizing that they are a way to pass general information down the call stack in an implicit manner without passing it.
<InPhase>
I really don't agree with anything on that pro/con list.
<InPhase>
Except the "unexpected places" one, which is a real issue.
howiemnt1 has joined #openscad
bitbasher has joined #openscad
howiemnt has quit [Ping timeout: 248 seconds]
califax has quit [Remote host closed the connection]
califax has joined #openscad
drfff has quit [Read error: Connection reset by peer]
<TylerTork>
I'm considering getting a new WIndows computer and wondering, from an OpenSCAD perspective, which specs matter for performance and what the point of diminishing returns is for those attributes?
<TylerTork>
E.g. I assume a faster processor is always better, but does the program take advantage of more threads? How much RAM can I add before I'm just throwing away money for no noticeable benefit? Does a dedicated graphics card and VRAM matter for this program?
<JordanBrown>
More RAM is almost never a waste. Unless you're getting a really big system, max it out. If nothing else it will get used for disk cache and improve everything's performance.
<TylerTork>
graphics card?
<TylerTork>
more threads?
bitbasher has quit [Ping timeout: 260 seconds]
<JordanBrown>
Sorry, distracted. I would expect a graphics card to help a little in display performance (that is, when rotating and panning the display), but I use built-in graphics and it's pretty rare that I see any sluggishness.
<JordanBrown>
Threads... not sure. Preview, no. Rendering, not sure... I think work has been done on making Manifold be multithreaded, but I don't know the status of that work.
<JordanBrown>
More VRAM, probably not.
<teepee>
manifold is multithreaded from the beginning
<JordanBrown>
Cool!
<teepee>
gpu does not help much at all, fast cpu memory is probably the best thing