Hi,
FM*MultivalueLink has a very confusing printOn: method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FM*MultivalueLink>>printOn: aStream
self asArray printOn: aStream ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Converting it to array means that when I see a variable in the inspector it describes itself as array which is quite confusing.
Maybe it should be wrapped?
printOn: aStream
self printNameOn: aStream. aStream nextPut: $(. self asArray printOn: aStream. aStream nextPut: $)
Thanks, Peter
I always had an issue with the inspector and printOn: in Moose
My use of the inspectr is in link with the debugger to understand the details of some behaviour. When I do debugging, I want to know precisely and accuratly what I am looking at. But because Moose redefines printOn: to be somehow user friendly, it often gets in the way by printing things that are not the real nature of the object.
This case is one example of my problem
I think the real solution should be to have two printing methods, one tor internal use (debugger, inspector) and another for users. The two are very different and they have different needs
nicolas
On 23/09/2015 13:58, Peter Uhnák wrote:
Hi,
FM*MultivalueLink has a very confusing printOn: method
FM*MultivalueLink>>printOn: aStream self asArray printOn: aStreamConverting it to array means that when I see a variable in the inspector it describes itself as array which is quite confusing.
Maybe it should be wrapped?
printOn: aStream
self printNameOn: aStream. aStream nextPut: $(. self asArray printOn: aStream. aStream nextPut: $)
Thanks, Peter
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
Moose does not redefine printOn: :). If some printOn: does not make sense, it's a bug and should be fixed.
For display purposes, we use mooseDisplayStringOn: and gtDisplayOn:. We should start to kill mooseDisplayStringOn:.
Doru
On Thu, Sep 24, 2015 at 10:09 AM, Nicolas Anquetil < nicolas.anquetil@inria.fr> wrote:
I always had an issue with the inspector and printOn: in Moose
My use of the inspectr is in link with the debugger to understand the details of some behaviour. When I do debugging, I want to know precisely and accuratly what I am looking at. But because Moose redefines printOn: to be somehow user friendly, it often gets in the way by printing things that are not the real nature of the object.
This case is one example of my problem
I think the real solution should be to have two printing methods, one tor internal use (debugger, inspector) and another for users. The two are very different and they have different needs
nicolas
On 23/09/2015 13:58, Peter Uhnák wrote:
Hi,
FM*MultivalueLink has a very confusing printOn: method
FM*MultivalueLink>>printOn: aStream self asArray printOn: aStreamConverting it to array means that when I see a variable in the inspector it describes itself as array which is quite confusing.
Maybe it should be wrapped?
printOn: aStream
self printNameOn: aStream. aStream nextPut: $(. self asArray printOn: aStream. aStream nextPut: $)
Thanks, Peter
Moose-dev mailing listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I guess it depends on one's defintion of redefining :-)
nicolas
On 24/09/2015 11:14, Tudor Girba wrote:
Hi,
Moose does not redefine printOn: :). If some printOn: does not make sense, it's a bug and should be fixed.
For display purposes, we use mooseDisplayStringOn: and gtDisplayOn:. We should start to kill mooseDisplayStringOn:.
Doru
On Thu, Sep 24, 2015 at 10:09 AM, Nicolas Anquetil <nicolas.anquetil@inria.fr mailto:nicolas.anquetil@inria.fr> wrote:
I always had an issue with the inspector and printOn: in Moose My use of the inspectr is in link with the debugger to understand the details of some behaviour. When I do debugging, I want to know precisely and accuratly what I am looking at. But because Moose redefines printOn: to be somehow user friendly, it often gets in the way by printing things that are not the real nature of the object. This case is one example of my problem I think the real solution should be to have two printing methods, one tor internal use (debugger, inspector) and another for users. The two are very different and they have different needs nicolas On 23/09/2015 13:58, Peter Uhnák wrote:Hi, FM*MultivalueLink has a very confusing printOn: method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FM*MultivalueLink>>printOn: aStream self asArray printOn: aStream ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Converting it to array means that when I see a variable in the inspector it describes itself as array which is quite confusing. Maybe it should be wrapped? printOn: aStream self printNameOn: aStream. aStream nextPut: $(. self asArray printOn: aStream. aStream nextPut: $) Thanks, Peter _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev-- www.tudorgirba.com http://www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Nicolas Anquetil -
Peter Uhnák -
Tudor Girba