On Mon, Nov 24, 2003 at 11:02:11PM +0100, Max Horn wrote:
> Am Montag, 24.11.03 um 08:38 Uhr schrieb Daniel Macks:
> >On Sun, Nov 23, 2003 at 07:54:36PM +0100, Max Horn wrote:
> >>Am Freitag, 21.11.03 um 10:08 Uhr schrieb Daniel Macks:
> >>>
> >>>Update of /cvsroot/fink/fink/perlmod/Fink
> >>>
> >>>Modified Files:
> >>>   ChangeLog Services.pm
> >>>Log Message:
> >>>Revert handling $prefix1/$prefix2 in print_breaking to the way it was
> >>>before removal of print_breaking_* (which seems to be the correct
> >>>behavior).
> >>
> >>May I ask what exactly this fixes? I.e. in which cases was the code
> >>causing problems?
> >
> >The previous change broke handling of prefixes that were logically
> >false. Consider what happens for
> >
> >  my $prefix1 = shift || "";
> >
> >if one passed the zero chacter.
> 
> Uhm, so? That's intended behavior then. Passing the "zero character"
> as a prefix is abuse of the function.

I would agree at this point.

> > That makes the shift false, so the null string is used instead.
> >(No, I can't find a place where this is actually done, but it's a
> >commonly-(mis)used idiom.)
> Ah so you didn't fix a problem, you just fixed a hypothetical issue 
> :-). That's all I wanted to know.

Yes. I'm pedantic like that.

>FWIW, I never have seen this "commonly-(mis)used idiom" anywhere...
>either you specify no prefix (so the default one is used), or you
>specify a legal (string) prefix.

Sorry if that was unclear. I meant in the world of perl, not in the
fink code. Some folks use || to select a default value if the caller
code doesn't pass anything because it's the closest "feels easy" way
to code it, but then it doesn't do what they meant.

> Passing a zero char is incorrect. So it seems to me we could have 
> either left the code as it was, or add an explicit check which makes 
> the code bail out if an illegal prefix was passed in :-)
> 
> >By switching (back) to checking that it's defined at all (even if 
> >logically false) this gotcha is removed.
> 
> I guess my irritation simply stems from the fact that I don't consider 
> this a gotcha - rather it's something you should never do... :-)

I can see that. I just thought it wasn't ideal to have "something you
should never do" simply due to an arbitrary limitation. I guess my
real question was why we are reimplementing Text::Wrap ourselves:)

> > I hear perl5.9 will have a new single operator that does what (I
> >assume, and therefore re-implmented) was meant. If not, obviously
> >feel free to undo the change.
> 
> I just got this feeling somebody might again change it back and forth 
> for whatever obscure reasons :-).

We'll always have ChangeLog and 'cvs log' to see what the heck
whomever was thinking. I assumed the origial code was the way it was
because it was logically correct (even if not pretty), and didn't see
a reason to deviate.

> I don't mind much either way, I just 
> thought the code was easiest to read the way I put it... YMMV.

Makes sense. If you undo change I won't redo it:)

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to