[GAP Forum] Forum discussion on packages and global function names

[Yevgen Muntyan]

Steve Linton wrote:
> On Thu, 03 May 2007 08:21:31 -0500
> Yevgen Muntyan <muntyan at tamu.edu> wrote:
>
>
>   
>> Why should Attributes be preferred to Operations? Does it make something
>> faster? We can have operation with the same name declared and defined
>> for totally different objects, so the only difference between operation and
>> attribute seems to be that attribute value is stored. Or is there something
>> else?
>>
>>     
>
> The reason is generality. If you declare something as an Attribute and never
> call it for any Attribute-storing object, then nothing is lost. But if you
> declare it to be an Operation, and someone comes along later and wants to use
> it for Attribute-storing objects, they will not be able to take advantage of
> the automatic storing and reuse of results.
>   
Sorry, I don't quite understand this. Suppose we have two categories
IsFoo and IsBar (not related at all), and the code:

DeclareOperation("Something", [IsFoo]);
# and elsewhere
DeclareAttribute("Something", IsBar);

Then Something(bar) will always invoke the appropriate method without
storing the result? What happens if "Something" is declared as an attribute
for two different types? (This is the question, what happens if you use
the name which is used in some other package or in the library, like Degree,
a good name which makes sense in given context; the name clash problem).

[snip]

>> [snip]
>>     
>>> I should say that there is one awkward exception to this generally good
>>> performance, namely when one of the arguments is a plain list with mutable
>>> entries. In this case determining its type must be repeated at every operation
>>> call, and can be expensive. We have some longer term plans to address this,
>>> but thy will involve significant changes and will take a while to work through.
>>>   
>>>       
>> Do you mean that it takes much time to distinguish between
>>
>> InstallMethod(Foobar, [IsList], ...)
>> InstallMethod(Foobar, [IsList and IsSomeCollection], ...)
>>
>> or any operation which has a method installed for a list is affected?
>>
>>     
>
> It has nothing to do with the Operation or the methods installed for it.
> Whenever an Operation is called, the types of each of the arguments is
> determined. Most of the time this is constant time, or, if significant work is
> involved, the results of the work are stored so that it will only need to be
> done once. For lists with mutable entries, however (not just mutable lists,
> but lists at least one of whose entries is a mutable object), this information
> cannot safely be stored, and so must be checked each time, and this can be
> expensive.
>   
Got it.

Thank you,
Yevgen