HaloO,
John M. Dlugosz wrote:
When I mentioned this before, there was big flack over mentioning the
way C++ did it. I think that must have been miscommunicated, since I
wasn't even talking about summing all the arguments when he brought up
Manhattan dispatch.
That he there being me, I just
TSa wrote:
BTW, what is a flack?
See http://en.wikipedia.org/wiki/Flak_%28disambiguation%29
Originally, (FL)ug(a)bwehr (K)anone -- German 88mm anti-aircraft cannon
of WWII.
Subsequently, any anti-air gun or cannon, particularly when fired at a
position rather than aimed at a particular
On 2008 May 7, at 4:21, TSa wrote:
BTW, what is a flack?
He's using flak (shrapnel; usual usage catching flak over ...)
without understanding it.
Coming back to how C++ handles static overloading. How is
the sort order of (int *), (int ), (int), (const int *),
(const int ), (const int),
--- John M. Dlugosz [EMAIL PROTECTED] wrote:
I want to review and collect the wisdom of what has been discussed
before. Someone mentioned this the other day, as being a significant
consensus. But I can't find anything in the forum archives.
Can someone point to the discussion, position
I'm still in the dark... I find an positions for manhattan distance
but no definition of what that is. I did find the alternative pod page
earlier.
--John
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:
--- John M. Dlugosz [EMAIL PROTECTED] wrote:
I want to review and
John ():
I'm still in the dark... I find an positions for manhattan distance but no
definition of what that is. I did find the alternative pod page earlier.
I don't have a whole answer for you, but a part that may help. What is
generally meant by Manhattan distance is so-called L1 distance,
Carl Mäsak wrote:
John ():
I'm still in the dark... I find an positions for manhattan distance but no
definition of what that is. I did find the alternative pod page earlier.
I don't have a whole answer for you, but a part that may help. What is
generally meant by Manhattan distance is
HaloO,
Mark A. Biggar wrote:
To do multi method dispatch, you want to select the method that best
matches the parameters in the call.
The fundamental flaw of metric mmd is that it trades degrees of
specificity. Consider the subtype chain E : D : C : B : A
where the rule is that having an E it
Mark A. Biggar mark-at-biggar.org |Perl 6| wrote:
To do multi method dispatch, you want to select the method that best
matches the parameters in the call. One way to do that is to define a
measure for distances between types and they use the method that's at
the minimum distance. One simple
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism demands that =every= parameter be at least as good
of a match, and one strictly better match. So the implementation never
guesses if worse-left/better-right is a better fit than
On Tuesday 06 May 2008 10:38:38 John M. Dlugosz wrote:
I have problems with a simple sum. The distance is artificially
inflated if you make lots of small derivation steps vs one large
change. The concept of derivation steps is ill-defined for
parameterized types and types that change
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading resolution
mechanism demands that =every= parameter be at least as good of a match,
and one strictly better match. So the implementation never
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism demands that =every= parameter be at least as
good of a match, and one strictly better match. So the
implementation never
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading resolution
mechanism demands that =every= parameter be at least as good of a match,
and one
On Tue, May 06, 2008 at 08:47:47PM -0500, John M. Dlugosz wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism
I want to review and collect the wisdom of what has been discussed before.
Someone mentioned this the other day, as being a significant consensus. But I
can't find anything in the forum archives.
Can someone point to the discussion, position papers, etc.?
--John
16 matches
Mail list logo
