Re: Please rename 'but' to 'has'.
Everyone I've ever talked to about it agrees that defining things to be a
negative is just a bad idea. Consider:
if (gronk) do_this();
else do_that();
versus
if (not_gronk) do_that();
else do_this();
It is one of the standard refactoring tricks to replace the second one
with the first. The word "has" is in the positive, whereas "but" is a
negative, but it assigns a positive, even more confusing.
The word "now" would be much nicer to indicate a change if you made it
orthogonal to the "has". So, use it as follows.
To assign a compile time property:
$a is now red;
To test a compile time property:
if ($a is red) {...}
To assign a runtime property:
$a now has green;
Who cares if the order is reversed. Make it work both ways.
To test a runtime property:
if ($a has green) {...}
Me wrote:
> I agree 'but' seems a tad odd, and I like the elegance of your
> suggestion at first sight. However...
>
> > First, but is just strange. I have a thing and I want to tell you it
> is
> > red, so I say 'but'. Huh?
>
> banana but red;
> "foo" but false;
>
> According to Larry, run time properties will most often be used
> to contradict a built-in or compile time property. If he is right
> about the dominant case being a contradiction, 'but' works
> better for me than anything else I can think of, including 'now'
> (explained below).
Re: Please rename 'but' to 'has'.
On Fri, 19 Apr 2002, Daniel S. Wilkerson wrote: > Please don't use 'but' to associate runtime properties to things. > Please call it 'has'. How about both? Luke
Re: Please rename 'but' to 'has'.
On Sat, 20 Apr 2002, Daniel S. Wilkerson wrote:
> Everyone I've ever talked to about it agrees that defining things to be a
> negative is just a bad idea. Consider:
>
> if (gronk) do_this();
> else do_that();
>
> versus
>
> if (not_gronk) do_that();
> else do_this();
But look how well C reads :) IMO, C is one of the best
readability decisions that Perl ever made.
> It is one of the standard refactoring tricks to replace the second one
> with the first. The word "has" is in the positive, whereas "but" is a
> negative, but it assigns a positive, even more confusing.
You wouldn't expect
$foobar but true
to actually be false, would you? So, I wouldn't say assigning a positive
is all that confusing.
> To assign a compile time property:
> $a is now red;
That uses too many of my precious keystrokes.
> To test a runtime property:
> if ($a has green) {...}
This brings up an interesting point.
if ($a but green) {...}
doesn't make a lot of sense. Would it be possible to make boolean C
test both runtime and compile-time properties? But I suppose that could
be confusing on the reader
Luke
Re: Please rename 'but' to 'has'.
In a message dated Sat, 20 Apr 2002, Daniel S. Wilkerson writes: > It is one of the standard refactoring tricks to replace the second one > with the first. The word "has" is in the positive, whereas "but" is a > negative, but it assigns a positive, even more confusing. "but" isn't a negative, not really. "but" can be read basically two ways in English, either as a synonym of "and" which happens to carry a tone of warning or things not being quite ordinary, or as a synonym for "except that". 0 but true Means "0 *and also* true, even though this isn't the usual state of affairs." Makes perfect sense to me. "has" makes no sense at all in this context. Were I to read: 0 has true my first reaction would be, "huh? Since when?" Or imagine a Color class, where you wanted to state that this black, if it were only just a bit brighter, would be green: $foo = Color.black but green; I think that "black has green" just sounds plain weird. "but" is absolutely perfect, Larry. I say keep it. Trey -- Trey Harris Secretary and Executive SAGE -- The System Administrators Guild (www.sage.org) Opinions above are not necessarily those of SAGE.
