[Novalug] Macro preprocessing

James Ewing Cottrell 3rd JECottrell3@Comcast.NET
Wed Jun 30 14:56:59 EDT 2010


You made some good points, but you missed the forest by looking at the 
trees. First, a differing number of arguments is the same as "differing 
types"; the unspecified arguments are of "void" type. But that is just 
splitting hairs.

But the argument about primitives vs Objects doesn't save you. 
Ultimately, they are just different "types".

My argument that overloading by parameters type is Limited still stands. 
Anytime you have two arguments of the same type, you simply cannot use 
overloading to distinguish them. Period. End of Story. You can't argue 
this point.

You picked on my examples without addressing the underlying points. To 
be clearer consider the Date constructor

     Date d = new Date(2, 14, 2010);
     Date e = new Date(14, 2, 2010);

Other than realizing there is no 14th month, there is no way to 
distinguish between the two forms, as all the arguments are int. Or make 
them a boxed Integer if you will.

This is where named arguments help because they ALWAYS work.

Furthermore, supposing that the Day argument in my example about was to 
be specified as a Float to make that possible, yow now need two 
declarations, one for Date::Date(float, int, int) and Data::Date(int, 
float, int).

OK, but now suppose you wanted to allow the Year first...perhaps you 
would demand it be a String to allow

Date f = new Date("2010", 2.0, 14);

Now you need six declarations.

Now you could indeed build Day, Month and Year classes to "solve" this, 
as in

Date h = new Date(new Month(2), new Year(2010), new Day(14));

I suppose you could use enums to create different "types" of ints, not 
quite as bad, but you still need six declarations and 5 dummy functions 
to pass to your "real" constructor. Of course, nobody needs 6 date 
constructors, but I could see 3 being needed.

Apologies for restating this all, but obviously it wasn't clear. Also, 
for the purposes of this discussion, ignore any existing Date classes; 
either assume that I get to define Date, or consider an analagous class, 
Daite and substitute that for Date above.

My second point was that I have never seen anyone use espouse 
overloading to get the effect of named parameters, and I consider such 
usage to be Bad Practice. Now clearly this is an Opinion, but I would 
guess it is widely shared.

JIM

On 6/29/2010 11:41 AM, Peter Larsen wrote:
> On Fri, 2010-06-25 at 21:53 -0400, James Ewing Cottrell 3rd wrote:
>    
>> On 6/25/2010 1:33 PM, Peter Larsen wrote:
>>      
>>> On Fri, 2010-06-18 at 20:44 -0700, Jim Ide wrote:
>>>        
> First off - sorry for the very late reply to this one.
>
>    
>>>> XML and XSLT come the closest to what I want, except that the
>>>> input text must be valid XML, and the XSLT template syntax
>>>> is cluttered, clunky, frustrating, and gives me a headache.
>>>> It also does not support parameter type checking.
>>>>
>>>>          
>>> I'll grab this one since it's sorta in the area I've been for about a
>>> decade now. Quickly though, in regards to named parameters that's
>>> solvable through overloading.
>>>
>>>        
>> Using overloading (and BTW, who does that besides C++ and Java?) to
>> provide named parameters is Limited at Best and Insane at Worst.
>>      
> Absolutely disagree. I think we have a small miscommunication here. Let
> me try to clarify.
>
>    
>> Overloading only works when arguments differ by Type.
>>      
> And the number of parameters. This is key.
>
>    
>> Thus, a date
>> scanning that appeals to folks on both side of the Pond (e.g. we write
>> Valentine's Day as 2/14 while Amy (note the cute Doctor Who reference)
>> writes it as 14/2.
>>      
> Depending on your platform, that really makes no difference. With both
> Java, C++ and PL/SQL (that uses overloading) "Date" is a separate
> object/type. It doesn't matter which timezone the date is in, or how
> it's represented externally - it's the same object being used - it's one
> object, no more, no less.
>
>    
>> Both are ints.
>>      
> No. They're objects (and in Oracle's case they're full decimal numbers).
> How the objects are represented doesn't matter. To the language Date,
> Calendar, Person etc. are all different objects and hence no conflict
> for the compiler to choose the right overloaded function/method. Even if
> the objects would happen to have the exact same number/type of
> attributes and methods, the objects are still not the same and
> differentiable to the compiler.
>
>    
>> And unless you want to make one a
>> double, or encode the month by biasing it by 100 or making it negative,
>> well, the language won't help you there.
>>      
> You're making the mistake of thinking primitive types. We rarely use
> them with OOP languages. In particular when it comes to something as
> complex as a date/time.
>
>    
>> Now it would be possible to appease both the Civilians (who write Feb
>> 14) and the Military (who write 14 Feb) by providing two overloaded fns,
>> scan_date(int, String) vs scan_date(String, int) because the two are of
>> different types.
>>      
> Sure it is. The user presentation of a date has no bearing on the
> internal object representation. A date is a date is a date. Even Julian
> vs. Gregorian dates are represented by the same object. They point to a
> "point in time". That's it.
>
>    
>> Add a third argument, and you are up to 6 different signature. Add a
>> fourth, and you are up to 24. And it is more or less at the 4th argument
>> where people's memory starts to fail them.
>>      
> It's still one argument. No more no less.
>
> To clarify, what I was referring to was context. Methods are usually
> called within context and by overloading, I simply specify the known
> contexts. That way, I know when called what values SHOULD be there, and
> if the context changes the way a method acts, it's easily shown and
> validated by using overloading. This means, that if I have a method with
> 30 possible parameters, that I don't make 30! (factor 30) different
> overloaded methods. I make only the number that makes sense from a
> business sense. So for instance, if the method is adding a new employee,
> I may make two overloaded methods, one for creating an employee through
> the normal HR interface and one that deals with migrating from another
> HR system. In one case, I have a reduced set of values and even special
> validation rules, in the other I need to more or less take the data raw
> and insert it - ie. even creating employees who are no longer with the
> company. But it's still a matter of adding an employee. I hope that
> clarifies what I meant.
>
>    
>> No, my friend, I don't believe that Function Overloading was ever
>> intended to provide Named Arguments; none of the books I have read ever
>> seem to make that case, altho you might find it in a book reviewed by
>> Leonard Pinth-Garnell (google him if you need to).
>>      
> Hopefully I made myself better understood above. You need to realize
> that only Object oriented languages (to my knowledge) uses overloading.
> And hence, talking primitive scalar types has no place here.
>
>    




More information about the Novalug mailing list