89 replies to this topic

[Jobo]

Not sure I would like this change, but let's not forget the possibility

+1 for that, my fine sir! +1 for that.

Even better would be draw.color.set() and draw.color.get()

Seeing as draw.color has no subclasses except Set and Get is would be stupid to make the library 'draw' with the sublibrary 'color' only to hold the classes 'set' and 'get'...

That it's popular doesn't mean it's good and should be pursued. I'm allergic to the "everybody does it" argument.

And that's not my argument for why I'd like to see it in GML either, that's just to answer your question as to why I am writing it in uppercase.
The java syntax is suiting me perfectly fine as well (lowercase) so that'd be fine too.

Oh well, GameMaker and its native scripting language are great as they are, though boring to program in, so no need to do major makeovers until YoYo Games get bored

[makerofthegames]

And why not draw.set_color?

You're violating syntax, only decreasing readability, ease-of-use and generally making it immensely unprofessional.

You're being insanely arbitrary from what I can see. How does that decrease readability? It's just a slight rearrangement of wording and less redundant. How is this unprofessional compared to any other wording? There's hardly any difference!

[scurvycapn]

I find it odd with all the discussion of object orientation and avenues for the language to go, that everyone seems hung up on using the same process to do things. Calling a command to set the current draw color that will be used until it is changed? Barf. Colors should be passed along in the drawing methods instead. I'd prefer something along the lines of this (inspired by the .Net Framework).

color rectColor = Color.Black;
color ellipseColor = Color.FromArgb(255, 255, 128, 64);
Drawing.DrawRectangle(rectColor, 32, 32, 128, 64);
Drawing.FillEllipse(ellipseColor, 256, 256, 64, 64);

[Jobo]

I would prefer that too, but that would totally restructure the GameMaker Language as opposed to us just discussing remaking its cosmetics.

[Erik Leppen]

Even better would be draw.color.set() and draw.color.get()

Seeing as draw.color has no subclasses except Set and Get is would be stupid to make the library 'draw' with the sublibrary 'color' only to hold the classes 'set' and 'get'...

draw.color.add(other_color)
draw.color.subtract(other_color)
draw.color.invert()
draw.color.red.get()
draw.color.green.get()
draw.color.blue.get()
draw.color.hue.get()
draw.color.saturation.get()
draw.color.value.get()
draw.color.red.set(new_red_value)
draw.color.red.add(red_increment)
draw.color.red.subtract(red_decrement)

If one has those functions for color, it wouldn't be that far-fetched to apply them to the drawing color as well. After all, if color is a class, all color methods go in that class.

And of course, if I define a new variable of type color, than all methods should apply to that variable as well.

Again, not sure this is what I'd like to work with though. I think the current method is clearer for novices, because you have a function and that's it. I think for non-programmers the idea of a function that "does stuff" is easier to grasp than the idea of a "method" that does stuff within a "class" of a certain "type".
I'd like a variable draw_color instead of functions, and then just use the color functions on that variable, and being able to assign values to the variable (draw_color = c_red).

Colors should be passed along in the drawing methods instead.

Why?

Instead of setting the color once and then drawing a load of stuff, you suggest that each and every draw call we have to re-enter the color? Why not do the same then with alpha and blend mode, circle precision, interpolation, and in d3d the fog, lighting, culling, hidden settings? Functions will have a whole lot of repeated arguments. Not sure I like that approach. But maybe it makes things clearer by leaving out "hidden arguments". I find that happens a lot with the _set and _get functions. I find myself frequently thinking "is culling on or off here? Oh well, let's just set it how I want it here.", ending up with a lot of unnecessary _set functions. Mainly in d3d though.

I don't know.

[GStick]

I would prefer that too, but that would totally restructure the GameMaker Language as opposed to us just discussing remaking its cosmetics.

No you wouldn't because that's exactly the same thing that I said to you and you argued against it.

[Dark Matter]

It's called syntax of one of the most popular programming languages ever written.

That it's popular doesn't mean it's good and should be pursued. I'm allergic to the "everybody does it" argument.

I much prefer the lower case for the first word, then capitals to separate them, personally (for methods). It looks untidy having all capitals in my opinion. Example: Draw.setColor().

Classes/Objects should start with capitals.

[scurvycapn]

^^^
I prefer methods to start with capitals. I dig Microsoft's naming standards since I work with C# most of the time.
http://msdn.microsoft.com/en-us/library/ms229043.aspx

Colors should be passed along in the drawing methods instead.

Why?

Instead of setting the color once and then drawing a load of stuff, you suggest that each and every draw call we have to re-enter the color? Why not do the same then with alpha and blend mode, circle precision, interpolation, and in d3d the fog, lighting, culling, hidden settings? Functions will have a whole lot of repeated arguments. Not sure I like that approach. But maybe it makes things clearer by leaving out "hidden arguments". I find that happens a lot with the _set and _get functions. I find myself frequently thinking "is culling on or off here? Oh well, let's just set it how I want it here.", ending up with a lot of unnecessary _set functions. Mainly in d3d though.

I don't know.

Yes, the idea of the user forgetting to set the color before the draw is one reason. It also can lead to easier to read code as you don't need to go looking for that method used to set the current draw color. It can also shorten the amount of code. You could store the color in a variable as I did in the example above to easily reuse it anywhere in a script or just call the color directly in each draw.

Drawing.DrawRectangle(Color.Black, 32, 32, 64, 64);
Drawing.DrawRectangle(Color.Red, 64, 64, 64, 64);
Drawing.DrawRectangle(Color.Green, 96, 96, 64, 64);

If I had to set my current draw color, I'd need three extra lines to set the color before I drew each rectangle. My dream would be GameMaker powered by C# with a framework similar to .Net.

[Schreib]

I don't know about C# very much, but one reason this type of capitalization could be confusing in Java (which allows nested types), in a manner similar to the example paul23 gave (about ambiguity) is if a variable is given a name exactly the same as a nested type. Consider the following Java code.

public class Thing {
    public int Variable = 42;
}

public class Stuff {
    public static Thing Nested = new Thing();

    public static class Nested {
        public static int Variable = 31;
    }

    public static void main(String[] args) {
        System.out.println(Stuff.Nested.Variable);
    }
}

Anyone who can tell me what the output is without compiling deserves a big warm hug from Schreib. (And don't pretend that this isn't ambiguous, either, to anything non-compiler).

Following the Java convention resolves the ambiguity:

public class Stuff {
    public static Thing nested = new Thing();

    public static class Nested {
        public static int Variable = 31;
    }

    public static void main(String[] args) {
        System.out.println(Stuff.Nested.Variable);
    }
}

Though again, it may seem weak to justify this solution by notation convention (which is why Hungarian notation is discouraged). Solving this ambiguity thoroughly would probably mean creating an operator that distinguishes between different kinds of qualification (in this case the . operator).

Edited by Schreib, 13 July 2012 - 11:24 PM.

[GStick]

Fields generally aren't caps with Microsoft's naming conventions. Properties and methods are though (because properties are basically getter and setter methods). So there's no real problem there. I think I've had names clash once in recent memory, and those were across different namespaces.