[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[pygame] the constructor functions ?????



i had changed the "constructor" type functions that simply
create a new type of object to use capitalize letters. after
toying with it for the day, i've decided it's either wrong, or
something else has to change.

Here's the deal. It turns out there are only 3 of these
constructor type functions in pygame. rect(), surface(), and
event(). once those are changed to Rect(), Surface, and Event()
they feel very out of place with the rest of pygame. i do
like the idea of differentiating these calls by capping them,
but it makes them feel very unique in the pygame library.

The specific question is, should the other constructor like
functions be changed in this manner?? for example, 
mixer.load() and mixer.get_channel() should become
mixer.Sound() and mixer.Channel()?? It seems to create a lot
of grey area. What about functions like image.load,
display.get_info(), etc, etc???

it seems like that is a situation that really can't be designed
cleanly. so the other option is to just say there are no class-
like constructors in pygame, everything is just done through
functions. this seems like a good road, since we can make the
whole thing very consistent. (/me likes)

the question then is, are the current names good enough?
the only decent thing i can think of as an alternative is
new_rect(), new_surface(), and new_event(). again, i kind
of like using the new_x() format, since it distinguishes
it as just a regular function.

the question is, is it worth the change? it seems like kind
of a big reversal to have started with rect(), wanted to
change to Rect(), but now wanting new_rect().

The good thing about Rect() is it has a more python-y feel
to it. The bad thing about Rect() is it makes things a bit
awkward, for example some objects are created from a simple
load() routine, while others are created from a class-like-
constructor.

the good thing about rect() is that it's just a normal little
function which is how all the different object types are created.
the other good news it's nice and short. the problem is that it's
a little ambiguos. it's got the same name as the object it creates
(no caps though) so is it really a function? it's got the same
name as the module it is from, pygame.event.event(). not at all
bad, but not totally clear either i'd say.

lastly there's new_rect(). the good thing about this is it
is very clear it's just a little 'ol function. it is very
clear what is going on and it fits in best with the image.load()
mixer.get_channel() and other type functions that create a new
object. the only strike against it is once again is once again
the level of verbosity goes up again. not much of a strike when
it's only 4 characters though.

does my little list of PRO/CON seem complete. what kind of
feeling do you others get about this? perhaps i'm just nit-
picking too much between "rect()" and "new_rect()" ?

when using the rectangle in equations it seems like the "new_"
would stick out a bit. example;
    >>> hit = new_rect(x, y, w, h).collidepoint(mouse_pos):
or
    >>> hit = rect(x, y, w, h).collidepoint(mouse_pos):
hmm, i guess it's not as bad as i though?


whew, after all that thought process, i feel the most comfortable
with adding the "new_" prefix to these 3 constructor functions.
most important of all i want to get this wrapped up fairly quickly,
this is another one of those "breaking changes" which i'd rather
get done sooner than later.

even if all you say is "i agree" or "whatever you think is best"
i'd be glad to see some replies on this :]


____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org