Re: [Php-tuxedo-development] PHP 4.1 changes

[Brian F. <bf...@mn...>]

On Fri, 28 Dec 2001 17:11:52 +0900, CheolMin Lee wrote:

>Returning "automatic FML type(16 or 32) decision" issue.
>
>The following is my old suggestion:
>
>>
>> Synopsis
>>   mixed tux_fget (resource FML_buffer, int field_id [, int occ])
>>
>>   Returns the corresponding the value of the field occurrence, or FALSE
>>   if some error occurs
>>
>>      FML_buffer is FML buffer resource reference
>>      field_id is FML Field identifier
>>      occ is occurrence number of the field
>>
>> I temporarily implemented this function takes not field name but field id
>> to indicate a field because of preserving consistency with tux_fadd, tux_flen,
>> etc. But, I think it is more convenient to take field name as the argument
>> when using in the real world. For example:
>>
>>   tux_fget($fmlbuf, tux_fldid("A_FIELD", TUX_FML));
>>
>>   vs.
>>
>>   tux_fget($fmlbuf, "A_FIELD"); /* FML or FML32 depends on $fmlbuf */
>>
>> Which one do you like?
>>
>
>Before next official release, how about changing argument type from
>field_id to field_name?  I've already got the code which working on my own
>project and finished field-test.
>
>Target functions for changing the argument type are:
>  tux_fdelall tux_foccur tux_fdel tux_flen tux_fpres tux_fadd tux_fget
>

CheolMin,

I face this with mixed thoughts.  Using the Field ID parameter
keeps it in sync with the raw Tux FML calls.  However I agree most 
people will probably have the
Field Name, not the ID.  Hence we would save them always calling
tux_fldid nested like that.  If they do still want to use Field ID,
they can nest tux_fname ($fieldID, TUX_FML32).

There is one other subtle factor in this decision...
In Tuxedo, a FML32 ID is defined as a unsigned long (32 bits).
However a PHP variable can only be a signed long.  Hence there
is the possibility of a very large Field ID that can't be properly
stored in a PHP variable or parameter.  This is a PHP limitation that 
isn't easy to get around.  If we encourage users to use the Field Name, 
we might reduce the likelyhood of hitting this.  I haven't looked
in depth at this, but its not been forgotten either.

Other thoughts?

Brian Douglas, have you ever seen a Field ID that fills up the
whole unsigned 32 bits?

I'm probably leaning towards changing the params, but can still
be swayed either way...

Brian