Re: Convenient Constructors

My opinion (which is all it could ever be when you are talking about personal policy or style choices like this) is that the second option would be preferable because it adheres to the Principle of Least Astonishment. In this case, the constructor method is called "new" which is pretty much what anyone approaching some unfamiliar code would expect.

Yes, it is a little more typing. So are comments and you include those in your code, I'm sure. The comments are just extra typing to help make the whole code more maintainable just like this slightly more verbose constructor.

It's your code, so by all means choose your own path. I would, however, recommend that if you decide to employ the first approach instead that the pod makes it abundantly clear that such methods are constructors in order to avoid any misconceptions.

So, are you writing a FF-style game or something else?

Comment on Re: Convenient Constructors - a Moo question

Replies are listed 'Best First'.
Re^2: Convenient Constructors - a Moo question by blindluke (Hermit) on Dec 06, 2014 at 18:37 UTC
Thank you for your reply. I understand that when it comes to style, it's mostly about opinions. But this is exactly what I expect, especially, when they are backed by some reasoning. Using new() is indeed clear and obvious, but this clarity in calling the method is somewhat balanced by the obscurity of BUILDARGS - someone reading the code would have to be familiar with this built-in method, while the additional constructors are self explanatory when you look at their implementation. Of course, one might say that the BUILDARGS method could be explained by one simple line of commentary at the point of its implementation, while the fact, that Attack->heavy is a constructor, will be obscure every time it's called. Still, your opinion puts the odds in favor of the second approach. And I don't care about more typing - when I said that the first method is shorter, I was trying to say that it looks clearer when it's read (due to the brevity of 'Attack->heavy'). It could be twice as long to type, if it meant that it would read like plain English. It was an unfortunate choice of words on my side, sorry. As to your question, no, I'm not making an FF clone. The game design is already done, and it works moderately well on pen&paper. It's a dungeon crawler, without any RPG elements - there is no character development at all, and no background story about your character. It's a series of monster encounters with turn based combat. You choose an attack, the enemy chooses a defense, there are some Games::Dice rolls, and the successful hits are applied. Then you switch sides and choose a defense, predicting the enemy's attack pattern. You have a few attack choices, and a few defense choices, and there is some rock-paper-scissors feel to the mechanics. Dodging works better against heavy attacks (with a chance to stun), parrying may result in a counter attack (but it's poor against heavy attacks). There are no more than three Attack / Defense options available to you at a given time (there is more variety for the enemies), and only two d10 rolls are made each turn. If I can make it look nice and simple, I'll post it under CUfP, and maybe someone will add some flavour to it. Some examples of the genre: Solo Dungeon Crawl Solo Tower Hack I would love to see a Perl implementation of the second one. If I did not have those attack/defense mechanics stuck in my head, this is where I would start - with a Tower Hack clone. Such simple design, so much fun. - Luke	[reply]

Replies are listed 'Best First'.

Re^2: Convenient Constructors - a Moo question
by blindluke (Hermit) on Dec 06, 2014 at 18:37 UTC

Thank you for your reply. I understand that when it comes to style, it's mostly about opinions. But this is exactly what I expect, especially, when they are backed by some reasoning. Using new() is indeed clear and obvious, but this clarity in calling the method is somewhat balanced by the obscurity of BUILDARGS - someone reading the code would have to be familiar with this built-in method, while the additional constructors are self explanatory when you look at their implementation. Of course, one might say that the BUILDARGS method could be explained by one simple line of commentary at the point of its implementation, while the fact, that Attack->heavy is a constructor, will be obscure every time it's called. Still, your opinion puts the odds in favor of the second approach.

And I don't care about more typing - when I said that the first method is shorter, I was trying to say that it looks clearer when it's read (due to the brevity of 'Attack->heavy'). It could be twice as long to type, if it meant that it would read like plain English. It was an unfortunate choice of words on my side, sorry.

As to your question, no, I'm not making an FF clone. The game design is already done, and it works moderately well on pen&paper. It's a dungeon crawler, without any RPG elements - there is no character development at all, and no background story about your character.

It's a series of monster encounters with turn based combat. You choose an attack, the enemy chooses a defense, there are some Games::Dice rolls, and the successful hits are applied. Then you switch sides and choose a defense, predicting the enemy's attack pattern. You have a few attack choices, and a few defense choices, and there is some rock-paper-scissors feel to the mechanics. Dodging works better against heavy attacks (with a chance to stun), parrying may result in a counter attack (but it's poor against heavy attacks).

There are no more than three Attack / Defense options available to you at a given time (there is more variety for the enemies), and only two d10 rolls are made each turn. If I can make it look nice and simple, I'll post it under CUfP, and maybe someone will add some flavour to it.

Some examples of the genre:

I would love to see a Perl implementation of the second one. If I did not have those attack/defense mechanics stuck in my head, this is where I would start - with a Tower Hack clone. Such simple design, so much fun.

- Luke

[reply]