accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken. -- Using Opera's mail client: http://www.opera.com/mail/
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self
seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken.
this is a part of visitor api for path segments. if you remove it, then
users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless.
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
On Fri, 27 Jan 2017 00:31:11 +0100, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self
seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken.
this is a part of visitor api for path segments.
I know but where is the visitor?
if you remove it, then users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless.
Where is the visitor? Why accept: are not packaged with it? Does it use DNU trick? In my imagine there is no implementor of moveSegment: closeSegment:
-- Using Opera's mail client: http://www.opera.com/mail/
--Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
On 27 January 2017 at 09:17, stepharong <stepharong@free.fr> wrote:
On Fri, 27 Jan 2017 00:31:11 +0100, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self
seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken.
this is a part of visitor api for path segments.
I know but where is the visitor?
if you remove it, then users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless.
Where is the visitor? Why accept: are not packaged with it? Does it use DNU trick? In my imagine there is no implementor of moveSegment: closeSegment:
why there should be any, if nobody using this feature, yet? so you don't have a single visitor. you could add a test case for coverage, so it won't bother you that there's no implementors of given selector in image :)
iirc, i used it for path transformation(s) code.. which then get removed. -- Best regards, Igor Stasenko.
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self
seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken.
this is a part of visitor api for path segments.
I know but where is the visitor?
if you remove it, then users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless.
Where is the visitor? Why accept: are not packaged with it? Does it use DNU trick? In my imagine there is no implementor of moveSegment: closeSegment:
why there should be any, if nobody using this feature, yet? so you don't have a single visitor.
you could add a test case for coverage, so it won't bother you that there's no implementors of given selector in image :)
Yes because it if keep dead code around we will have a broken house window syndrome and I do not like it.
iirc, i used it for path transformation(s) code.. which then get removed.
Was it removed because it was not good, ? no useful? or just a mistake?
--Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
On 29 January 2017 at 16:16, stepharong <stepharong@free.fr> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self
seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken.
this is a part of visitor api for path segments.
I know but where is the visitor?
if you remove it, then users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless.
Where is the visitor? Why accept: are not packaged with it? Does it use DNU trick? In my imagine there is no implementor of moveSegment: closeSegment:
why there should be any, if nobody using this feature, yet? so you don't have a single visitor. you could add a test case for coverage, so it won't bother you that there's no implementors of given selector in image :)
Yes because it if keep dead code around we will have a broken house window syndrome and I do not like it.
iirc, i used it for path transformation(s) code.. which then get removed.
Was it removed because it was not good, ? no useful? or just a mistake?
well, i think there's some kind of duplication.
if you look at base class - AthensPathSegment there's two methods for visitor pattern: #accept: and #sendCommandsTo: the main difference between the above two is that #accept: should double-dispatch with appropriate message passing single argument - the receiver, while #sendCommandTo: is used by a convenience protocol #sendCommandsTo: that sends direct _series_ of commands to visitor in a fashion like: visitor lineTo: aPoint; curveVia: aPoint to: endPoint etc. Mainly, sendCommandsTo: is for convenience, that does not requires the user to implement a loop in own code, and to allow user to deal directly with data instead of subinstances of AthensPathSegment. Also, as i looking into code, there are some leftovers - the #convertWith:, and #visitWith: . These should be removed and users of #visitWith: should be refactored to #accept: protocol. To not confuse users what exactly protocol should be used.
-- Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
Ah, yeah.. one important note: #sendCommandsTo: is used to convert backend-neutral path data to backend-specific paths. That means , that commands that implementor should use , should conform with AthensPathBuilder protocol, so that you can later do: backendSpecificPath := canvas createPath: [:builder | myBackendNeutralPathData sendCommandsTo: builder]. On 29 January 2017 at 17:41, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 January 2017 at 16:16, stepharong <stepharong@free.fr> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
accept: aVisitor ^ aVisitor lineSegment: self accept: aVisitor ^ aVisitor closeSegment: self accept: aVisitor ^ aVisitor moveSegment: self
seems to invoke methods that do not exit I check AthensLIneSegment is used so I do not understand why the methods are broken.
this is a part of visitor api for path segments.
I know but where is the visitor?
if you remove it, then users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless.
Where is the visitor? Why accept: are not packaged with it? Does it use DNU trick? In my imagine there is no implementor of moveSegment: closeSegment:
why there should be any, if nobody using this feature, yet? so you don't have a single visitor. you could add a test case for coverage, so it won't bother you that there's no implementors of given selector in image :)
Yes because it if keep dead code around we will have a broken house window syndrome and I do not like it.
iirc, i used it for path transformation(s) code.. which then get removed.
Was it removed because it was not good, ? no useful? or just a mistake?
well, i think there's some kind of duplication.
if you look at base class - AthensPathSegment there's two methods for visitor pattern: #accept: and #sendCommandsTo:
the main difference between the above two is that #accept: should double-dispatch with appropriate message passing single argument - the receiver, while
#sendCommandTo: is used by a convenience protocol #sendCommandsTo: that sends direct _series_ of commands to visitor in a fashion like: visitor lineTo: aPoint; curveVia: aPoint to: endPoint etc.
Mainly, sendCommandsTo: is for convenience, that does not requires the user to implement a loop in own code, and to allow user to deal directly with data instead of subinstances of AthensPathSegment.
Also, as i looking into code, there are some leftovers - the #convertWith:, and #visitWith: . These should be removed and users of #visitWith: should be refactored to #accept: protocol. To not confuse users what exactly protocol should be used.
-- Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 29 January 2017 at 16:16, stepharong <stepharong@free.fr> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
Yes because it if keep dead code around we will have a broken house
window syndrome and I do not like it.
You don't have to advocate that to me. I am fully on your side with this :) -- Best regards, Igor Stasenko.
On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 January 2017 at 16:16, stepharong <stepharong@free.fr> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
Yes because it if keep dead code around we will have a broken house window syndrome and I do not like it.
You don't have to advocate that to me. I am fully on your side with this :)
excellent! Can you propose a slice so that we fix the code?
--Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
Why do not we have that concept of -contrib like there is in so many other places? Packages are release with the official party line and there is a -contrib package, or contrib/ subfolder that contains extensions and other useful bits that are not "core" but are still useful for people and do not require a hunt to figure out that they do exist? Phil On Sun, Jan 29, 2017 at 6:16 PM, stepharong <stepharong@free.fr> wrote:
On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 January 2017 at 16:16, stepharong <stepharong@free.fr> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
Yes because it if keep dead code around we will have a broken house
window syndrome and I do not like it.
You don't have to advocate that to me. I am fully on your side with this :)
excellent!
Can you propose a slice so that we fix the code?
-- Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
In any case, this kind of "dead code that is better said an unused feature could be used and made explicit in the system by implementing a test on it, doesn't it? On Mon, Jan 30, 2017 at 7:42 AM, phil@highoctane.be <phil@highoctane.be> wrote:
Why do not we have that concept of -contrib like there is in so many other places?
Packages are release with the official party line and there is a -contrib package, or contrib/ subfolder that contains extensions and other useful bits that are not "core" but are still useful for people and do not require a hunt to figure out that they do exist?
Phil
On Sun, Jan 29, 2017 at 6:16 PM, stepharong <stepharong@free.fr> wrote:
On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 January 2017 at 16:16, stepharong <stepharong@free.fr> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
Yes because it if keep dead code around we will have a broken house
window syndrome and I do not like it.
You don't have to advocate that to me. I am fully on your side with this :)
excellent!
Can you propose a slice so that we fix the code?
-- Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
On 29 January 2017 at 19:16, stepharong <stepharong@free.fr> wrote:
On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko <siguctua@gmail.com> wrote:
On 29 January 2017 at 16:16, stepharong <stepharong@free.fr> wrote:
On 27 January 2017 at 00:06, stepharong <stepharong@free.fr> wrote:
Yes because it if keep dead code around we will have a broken house
window syndrome and I do not like it.
You don't have to advocate that to me. I am fully on your side with this :)
excellent!
Can you propose a slice so that we fix the code?
Right now i can only propose if someone else propose the slice.. I don't have much free time on doing things on the side, even if i would like to do it... I am not the God, and as you know already , my brains working well only if they are in single-threaded mode :) -- Best regards, Igor Stasenko.
participants (4)
-
Guillermo Polito -
Igor Stasenko -
phil＠highoctane.be -
stepharong