Objects

[Gan]

Call it whatever you want, a name is not worth fighting over.

@Eq: It's the same as your string array method, just a bit more advanced. It gives a name to each piece of data inside the string array. Allowing for easier organization. Also includes one line getting and setting of certain values inside the string array.

P.S. I've never used a struct, only Classes. The functionality I've duplicated in this I have taken directly from Classes.

[Charlo]

X is right, what we're doing here is replicating the functionality of the attributes of objects.  All other things that he mentioned (like data hiding, polymorphism and methods) would be significantly harder to achieve, and until we do all those things we don't have objects.

For instance methods you could try defining a global method which takes as parameters both the normal method parameters and a parameter for the object that is calling it.  Then the method is executed ONLY if the caller object is correct.  The same could be done for data hiding, making getter and setter methods for every instance variable and only returning the value of the variable if the caller object is correct.  Of course, since there is no "private" in SC, no data is ever truly hidden.

I can't think of any way to do polymorphism.  At this point I think I would just want to program in Java or something.

[x]

Basically all you have done is replicate the functionality of a struct, and claim its an object because the name is less confusing (which is more confusing in and of itself).

Data hiding is plausible, just make sure all the values are stored in your array string and marked as either public or private. And make your getter method only return public ones.

"private foo=100,public bar=10"

For methods it could be done very simply as follows. Have a function that takes an object (they are objects now if they have data hiding and methods) as its parameter, checks if its the right object type and uses that objects attributes to perform the method:

CLASSNAMEMETHODNAME(object)

Polymorphism would be easy, just do a type check in the method. Done.

Inheritance is the hard bit.

[Gan]

In a non-C related programming language where other terms aren't known, the name object makes complete sense.
An object has attributes, certain definable characteristics.
This is what my code accomplishes.
For example there's a cube in front of you. Lets say it's the color red, is 5 inches in length, and is 1 pound.
In Sc that cube would be an object with those attributes defined.

From an inexperienced user's viewpoint this name makes perfect sense.
I'm sure you guys are correct in your terminology.

[x]

In a non-C related programming language where other terms aren't known, the name object makes complete sense.
An object has attributes, certain definable characteristics.
This is what my code accomplishes.
For example there's a cube in front of you. Lets say it's the color red, is 5 inches in length, and is 1 pound.
In Sc that cube would be an object with those attributes defined.

From an inexperienced user's viewpoint this name makes perfect sense.
I'm sure you guys are correct in your terminology.

You are incorrect, a STRUCT has attributes and certain definable characteristics. An object also has methods and data hiding, as ive said multiple times.

You are calling an apple and orange because you claim it makes more sense.

Anyways, in my above post I gave ideas how you could fake actual objects.

[Gan]

In a non-C related programming language where other terms aren't known, the name object makes complete sense.
An object has attributes, certain definable characteristics.

Reread?

[x]

Reread?

I have read it, its still wrong.

A struct is a generic programming paradigm. So is an object.

Theres an easy solution though, make them into real objects instead of struct by follow the advice Charlo and I gave.

[x]

Interesting, you could theoretically define an object within and object and have an array within an array here. Hence 2d arrays.

[WarHampster]

Step one: leave for a year

Step two: come back all wise and cynical

Step three:

Step four: profit

Chill, x.

[Gan]

@WarHampster,(unrelated question) by any chance have you read this article? http://arstechnica.com/science/news/2011/01/this-space-left-blank-the-role-of-placeholders-in-science.ars

@X, In my last 2 posts I was defining a real world object. Not a C or other programming language object.
I was trying to say that an object is something with physical attributes. I.E. a cube that's red, ect, ect.
The reason I named this code an object is because it relates with what a beginner programmer knows. Objects in the real world. See where I'm coming at?

[WarHampster]

Gan - I hadn't, but I have now. Very cool stuff. I love how they described Bohr's use of neutrinos as a "hack."

Also, x, SC calls its functions "methods," which they are technically not because they do not belong to classes.

[x]

Gan - I hadn't, but I have now. Very cool stuff. I love how they described Bohr's use of neutrinos as a "hack."

Also, x, SC calls its functions "methods," which they are technically not because they do not belong to classes.

The method thing is a bit iffy too. But my problem is not with syntax, its with semantics, plus thats not what this thread is about. Also I was wise (not really) and more-so cynical (not too mention opinionated!) at least a year or two before my year long exodus, so your argument and humorous 4chan culture reference is invalid.

@Matt: I was never saying it had anything to do with C programming. Objects are found in more than just C oriented languages, in fact OOP is pretty much ubiquitous. You claim that you are trying to make it easy for beginners by calling it and object, in my opinion thats exactly the kind of confusing cr*p that puts intermediate programmers off learning new languages, or starts bad habits. Call it what you want, but don't claim its an object. This is NOT OOP. Whats the problem with calling it a structure, which is what it actually is... Besides it makes just as much sense to call a cube a structure.

Don't take any of this personally, I just hate things that are mislabeled.

[Silverwind]

An object, such as a weapon, a dragon or a castle, is a thing with characteristics, such as size, shape, colour etc. Therefore I doubt the name "object" will confuse anyone when used to refer to the collective group of variables that represent the object.

[x]

An object, such as a weapon, a dragon or a castle, is a thing with characteristics, such as size, shape, colour etc. Therefore, I doubt there'll be any confusion in referring to the collective group of variables which represent an object's characteristics as an "object".

check out struct: http://en.wikipedia.org/wiki/Struct_(C_programming_language)
Is that not exactly what this is?

My point was that there WILL be confusion when someone goes to learn a proper OOP language and sees objects, then they don't work at ALL the way they learnt them. A "struct" is the programming paradigm which has been created/described here, is a castle not a structure as much as its an object? Wouldn't it make sense to name this using the correct programming paradigm?


Which I have already said before.

Please read my posts before you criticize me for a moot point.  

[Silverwind]

I can only speak for myself, Gnome and Eq, but none of us were very surprised to learn that our simplistic card based development systems used dumbed down commands and features from the high level languages they were built in, whilst retaining the names they were based on.

I've never met a kid with a cork-pop riffle who couldn't understand why people referred to it as a gun, when clearly it was a toy. In the same way, this list of variables represents an object, thus the naturally obvious thing to name it is an object.