Open ThomasBreuer opened 1 month ago
No, apparently the CI tests do not complain about the proposed change. So is this a reasonable solution to Leonard's problem?
Would this really be a good idea? -- I mean, for example assume you name an object "X". Then, as I understand, with your proposal this would still be "Print"ed as "X", as there is a global variable named "X". (Or did I misread something?)
@Stefan-Kohl
Would this really be a good idea? -- I mean, for example assume you name an object "X". Then, as I understand, with your proposal this would still be "Print"ed as "X", as there is a global variable named "X". (Or did I misread something?)
Well, this has been the behaviour since more than 25 years, and nobody has reported a problem with it.
Yes, one can set misleading names. If a user does this then it is his/her fault, and View
will continue showing these names. (I think that function names such as X
cause less confusion than names of objects such as Rationals
.)
I think that Name
should not be set by library functions, but this is another question to be answered.
This addresses #5699.
For more than 25 years, there is a
PrintObj
method with high rank that just prints a knownName
value of the object in question. According to the documentation ofName
, a knownName
value should be used only byView
andViewObj
; the functionPrint
is recommended to show GAP input to reconstruct the object in question if this makes sense.When we remove the
PrintObj
method in question, the tests fromtestinstall
andteststandard
show differences essentially in two situations:Rationals
are currently expected to be printed via this name. The solution proposed here is to provide aPrintObj
method with high rank that uses a known name under the condition that a global variable with this name exists.SimpleGroupsIterator
callPrint
in order to show the names of these groups. Here we can callView
instead ofPrint
.(Let us see the results of the other tests, perhaps there are more differences.)