in reply to Re (tilly) 1: Dice::Dice
in thread Dice::Dice

I don't see it as a problem to have a method for remembering how many sides the die has, especially since it's two real lines of code and the instance has to have that in order to useful (so it's persistent data anyway). Since he is doing this as a learning exercise, it's a good point to be made though.

As far as dice objects go, I prefer to have a Face attribute, which does hold the most recent roll. Completely useless in many circumstances, but what if this is for a game of Yahtzee? Then the number on the top of the die is very important. Also, as an amusing trick, I'd like to see an OppositeFace () method.

By carefully abusing list vs. scalar context, the same method can be made to return a single roll or a list of several rolls (of the same die). Also useful would be a sum method to total up several rolls into a single scalar result.

Gee, I'm glad I have no idea what a pseudo-hash is given it's shaky future. I would have used "our" to create a default hash if it were really needed, but prefer to simply set the defaults in the new constructor.

Replies are listed 'Best First'.
Re (tilly) 3: Dice::Dice
by tilly (Archbishop) on Jan 08, 2001 at 02:32 UTC
    Thank you for reminding me. Default values are something that is good to make a method from if you want them inherited in an override. His implementation of defaults tries to do that but will blow up because he will try to be using a symbolic reference and has strict on.

    As for the accessor method, I provided one accessor where he provided 2 setters and 2 getters. Then I didn't use mine internally, while he used his a lot. I think that the difference is substantial.

    You do have a good point about the needs of Yahtzee vs the needs of role-playing games. However if you wanted to reuse this module for Yahtzee, why not provide a subclass that adds the face attribute? Just because something is sometimes useful doesn't mean that you want to always do it. Instead be reasonably efficient by default but provide an interface that can be extended easily.

    As for a sum method, depending on your situation that might or might not fit in the class. In role-playing games you often see rolling a lot of dice and summing them up. But you also see a lot of rolling several dice and summing up some subselection. (Usually the top m of n.) In games such as backgammon you really don't want to sum them, but you do care about doubles. In short it doesn't need to happen by default though it may be convenient often enough to provide it.

    As for what a pseudo-hash is, it is an anonymous array whose first element is a hash saying what the following entries are. In short it acts a lot like a C struct. And if you do a lot of declarations Perl will actually resolve the lookup through the hash element at compile time and the accesses will be faster as well.

    Unfortunately it looks to be history. But you might as well remember this for reuse as a future trivia question.

    What feature was left out of Perl 6 because it caused serious performance problems in the first attempt to write Perl 6?

      I have a question concerning this comment of yours,

      Default values are something that is good to make a method from if you want them inherited in an override. His implementation of defaults tries to do that but will blow up because he will try to be using a symbolic reference and has strict on.

      Inheritance is everything in this module so I'm trying to grok this. My english2perl isn't what it should be (yet). While I was working on this I made sure that Dice::di's roll method was inherited into Dice::Dice before I overroad it, and I had no problem. So obviously you are trying to warn me of something I don't know how to identify in the code.

      Please help in assisting the blind to see,

      coreolyn

        The following code is what bothered me:
        my %defaults = $caller_is_obj ? %$caller_is_obj : %_default_data;
        Instead of that do the following:
        my %defaults = $caller->get_default();
        and in your module define a get_default() method that returns the same data you put in %_default_data.

        Either that or change to:

        my %defaults = $caller_is_obj ? %$caller : %_default_data;
        (which upon reflection is more likely what you meant).
Re: (ichimunki) Re (tilly) 1: Dice::Dice
by salvadors (Pilgrim) on Jan 08, 2001 at 02:11 UTC

    By carefully abusing list vs. scalar context, the same method can be made to return a single roll or a list of several rolls

    Why would this be abusing context? That is exactly what wantarray is for ...

    Also, as an amusing trick, I'd like to see an OppositeFace () method.

    sub opposite_face { my $self = shift; return $self->{size} - $self->{face} + 1; }

    Tony

    Update: DOH!

      Re: Context: I know it's not really abuse. Poor choice of words.

      That should probably be  return $self->{size} + 1 - $self->{face};. Yours returns 13 on a six-sider with a six up. The answer is one. Of course, we also need a sanity check that it's an even number of sides not equal to 4 (since four sided dice are pyramid shaped).

      Note: I think I am a little too into dice. :) Update: the opposite face formula in the preceding post is correct at this time. I still maintain a need to sanity check whether the die has opposing face.
        Update: This post is not relevant.
Re: (ichimunki) Re (tilly) 1: Dice::Dice
by coreolyn (Parson) on Jan 08, 2001 at 20:13 UTC

    Call me dense but I'm not understanding the difference between a 'face' attribute and the array held in the 'Results' attribute.

    As for an OppositeFace() method I don't think I'll be chasing that one for a while :)

      Untested, for illustration only.
      sub new { my $Di = { Sides => 6, Face => 1 }; #default six sider, sitting with 1 up bless $Di, "Dice::Di"; } sub Roll { my $self = shift; my $newface = int( rand( $self->{'Sides'} ) + 1); $self->{'Face'} = $newface; return $newface; } sub Rolls { #call with @results = $Di->Rolls( integer ); my $self = shift; my $times = shift; my @faces; for (1..$times) { my $rolled = $self->Roll(); push( @faces, $rolled ); } return @faces; } sub CurrentFace { my $self = shift; return $self->{'Face'}; }
      If you really want to be able to know every roll this particular Di has ever yielded you could add History => (), to the new method and push $newface onto that during Roll(). I would avoid this unless it were heavily restricted in the implementation. Also, using the wantarray function (or even detecting the presence of an argument) you can easily have the Roll() method detect whether or not it should act like the Rolls() function and return a list, or just roll once and return that as a scalar. Does this help?

        I see where you're comming from. Following these lines of thought I'll need a Dice::blow-on() routine too! :)

        I like the way your looking at this, and I really like the 'History' method, it gives a 'personality' aspect to the di. I'm still pondering the 'face' value though as no matter what face is up a person still 'rolls' the di, unleass the 'last-face' value was somehow worked into the random seed... hrmmm... hrmmm....

        coreolyn