August 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Marcus Denker

We will kick you out if you send crap to this list. One more mail like that and you are out. > On 01 Aug 2015, at 15:41, Kjell Godo <squeaklist(a)gmail.com> wrote: > > is there anybody > > here > > who knows both > > Haskell and Smalltalk ? > > Can Smalltalk benefit from > > functional ideas > > and > > Haskell's ideas about > > Immutability > > Currying > > Function composition and > > the State and IO Monads ? > > I like the way Haskell is now based on > > Category Theory > > which is the mathematics of > > function composition . > > Haskell was not always thus > > it had a > > pre Category Theory > > epoch . > > which apparently > > was a UM or > > Ugly Mess . > > Can these ideas be applied to > > Smalltalk? > > And would it be good? > > Can Smalltalk have a way of making a > > framework > > that has an > > API > > and is statically typed inside > > using a Haskell like type system? > > On Saturday, August 1, 2015, Kjell Godo <squeaklist(a)gmail.com <mailto:squeaklist@gmail.com>> wrote: > > > On Monday, July 6, 2015, Eliot Miranda <eliot.miranda(a)gmail.com <javascript:_e(%7B%7D,'cvml','eliot.miranda(a)gmail.com');>> wrote: > Hi Kjell, > > On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist(a)gmail.com <>> wrote: > >> Thank you for the detailed reply Andreas >> >> >> >> Are there any Smalltalk packages implementing >> >> Category Theory based >> >> functional programming constructs >> >> for function composition like >> >> functors , applicatives , monads , arrows , etc ? >> >> >> >> Do people have opinions about whether or not >> >> these plus immutable data structures would be good for managing state >> >> in Smalltalk like they do it in Haskell etc? i know that monads are not built >> >> into Haskell but are implemented as addons via Haskell packages. >> >> My Haskell friend said all you need to do functional programming is >> >> first class functions >> >> which Smalltalk Block contexts almost are except they lack their own stack? >> >> if you wrap a Block in a Function Object do you then get the stack >> >> effect so you can essentially call the Block recursively? > > The Pharo & Squeak dialects, along with most others, now have closures, so blocks are fully recursive. > >> >> i have been wondering about taking a crack at implementing these >> >> in Smalltalk and i wonder if it would be >> >> theoretically possible >> >> to speed them up by inlining them via the Smalltalk compiler > > The compiler already inlines closures in a few key control messages such as ifTrue: whileTrue: and:. > > > I recommend spending some time reading the code for the core execution classes and the compiler, and running examples interactively to learn how the system works. It's a fun process and well supported by the tools. Remember that the debugger includes a meta circular interpreter for executing the system's bytecode, and that the compiler compiles source to bytecode in the firm of CompiledMethod instances you can inspect, decompile and list their bytecode. > > All the questions you have above you can answer for yourself by running examples and using the tools to observe what happens. This is a route to mastering the system; IMNERHO the best. > > > is there any tutorial? > > how do i do this? > > >> Thank you > > Eliot (phone) > > >> On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de <>> wrote: >> >>> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com <>>: >>> >>> This is off topic. >>> >>> I tried to post it as a top level thread but I have become unknown. >> Why do you expect that? Many people here are using Smalltalk for years. >> Just because you have been silent for some time doesnât mean everybody will forget about you :) >> >>> >>> I don't know if you want this crap in here but I have decided not to wait for the >>> >>> postmaster to get back to me on the subject of becoming known. Feel free. >>> >>> >>> >>> >>> >>> ( Original-SUBJECT: "( picoVerse-:( what about state , is state really evil? ) )" ) >>> >>> >>> >>> >>> >>> >>> I am a Smalltalker. >>> >>> But in the past few months i have been running with the Haskellers. >>> >>> The Haskellers hate state. >>> >>> This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. >>> >>> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >>> >>> The debugger is my staff I use to whack the state. And TestCase is my sheep dog. >>> >>> But to the Haskellers >>> >>> state is >>> >>> the evil trinity >>> >>> of >>> >>> satan the anti christ and the false prophet >>> >>> all rolled into one. >>> >>> State is the true dev incarnation of the total catastrophe of development Armageddon. >>> >>> Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. >>> >>> They say. >>> >>> I'm not sure i quite get it yet but they keep preaching on this one point most of all. >>> >>> State is evil. >>> >>> You must keep all state in a Monad. As many methods/functions m as possible >>> >>> must be 100% dependent on the input parameters ONLY. >>> >>> No hidden instance variables affecting the return value of m are allowed. >>> >>> The only effect m can have is to return a value. >>> >>> If all this is true then m is pure. >>> >>> And pure is good. Pure is very good. And the wind says >>> >>> very. >>> >>> So i wonder if any of you fellow >>> >>> Smalltalkers >>> >>> have thought about this at all. >> >> First, there are no good definitions of what is an object oriented language and what is a functional language. >> Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalkâs. >> The same problem exists in the functional language world: Some consider LISP being functional, some deny that. >> >> Second, for some years I am constantly seeking for âthe bestâ language to solve my problems in. Alas I wasnât successful yet and donât expect >> to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems. >> So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the >> best fitting language for your problem at hand. >> >> Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >> the best characteristics. In my eyes all of them failed because what always have been created is Frankensteinâs monster. When you combine >> paradigms you will may get some advantages of all but sure you will get a lot of additional complexity. >> >> Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. Itâs the whole system: the language, duck typing, >> the image (object world), the tools, the VM, the simplicity, the elegance, â¦ And last but not least the communities around. >> >> Regards >> Andreas >> >> PS: If you are interested in functional programming and donât like static typing you should have a look at Clojure. It has some nice ideas about >> how to deal with state concurrently. >> >> >> >>> Thanks >>> >>> Kjell E GodÃ¸ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (((((((((( Maybe Smalltalk should be called Statewalk >>> >>> as in yak it up fuzz ball. )))))))))) >>> >>

Aug. 1, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

is there anybody here who knows both Haskell and Smalltalk ? Can Smalltalk benefit from functional ideas and Haskell's ideas about Immutability Currying Function composition and the State and IO Monads ? I like the way Haskell is now based on Category Theory which is the mathematics of function composition . Haskell was not always thus it had a pre Category Theory epoch . which apparently was a UM or Ugly Mess . Can these ideas be applied to Smalltalk? And would it be good? Can Smalltalk have a way of making a framework that has an API and is statically typed inside using a Haskell like type system? On Saturday, August 1, 2015, Kjell Godo <squeaklist(a)gmail.com> wrote: > > > On Monday, July 6, 2015, Eliot Miranda <eliot.miranda(a)gmail.com > <javascript:_e(%7B%7D,'cvml','eliot.miranda(a)gmail.com');>> wrote: > >> Hi Kjell, >> >> On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist(a)gmail.com> wrote: >> >> Thank you for the detailed reply Andreas >> >> >> >> Are there any Smalltalk packages implementing >> >> Category Theory based >> >> functional programming constructs >> >> for function composition like >> >> functors , applicatives , monads , arrows , etc ? >> >> >> >> Do people have opinions about whether or not >> >> these plus immutable data structures would be good for managing state >> >> in Smalltalk like they do it in Haskell etc? i know that monads are not >> built >> >> into Haskell but are implemented as addons via Haskell packages. >> >> My Haskell friend said all you need to do functional programming is >> >> first class functions >> >> which Smalltalk Block contexts almost are except they lack their own >> stack? >> >> if you wrap a Block in a Function Object do you then get the stack >> >> effect so you can essentially call the Block recursively? >> >> >> The Pharo & Squeak dialects, along with most others, now have closures, >> so blocks are fully recursive. >> >> >> i have been wondering about taking a crack at implementing these >> >> in Smalltalk and i wonder if it would be >> >> theoretically possible >> >> to speed them up by inlining them via the Smalltalk compiler >> >> >> The compiler already inlines closures in a few key control messages such >> as ifTrue: whileTrue: and:. >> >> >> I recommend spending some time reading the code for the core execution >> classes and the compiler, and running examples interactively to learn how >> the system works. It's a fun process and well supported by the tools. >> Remember that the debugger includes a meta circular interpreter for >> executing the system's bytecode, and that the compiler compiles source to >> bytecode in the firm of CompiledMethod instances you can inspect, decompile >> and list their bytecode. >> >> All the questions you have above you can answer for yourself by running >> examples and using the tools to observe what happens. This is a route to >> mastering the system; IMNERHO the best. >> >> > is there any tutorial? > > how do i do this? > > >> >> Thank you >> >> >> Eliot (phone) >> > > >> >> On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de> >> wrote: >> >>> >>> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >>> >>> This is off topic. >>> >>> I tried to post it as a top level thread but I have become unknown. >>> >>> Why do you expect that? Many people here are using Smalltalk for years. >>> Just because you have been silent for some time doesnât mean everybody >>> will forget about you :) >>> >>> >>> I don't know if you want this crap in here but I have decided not to >>> wait for the >>> >>> postmaster to get back to me on the subject of becoming known. Feel >>> free. >>> >>> >>> >>> >>> >>> ( Original-SUBJECT: "( picoVerse-:( what about state , is state >>> really evil? ) )" ) >>> >>> >>> >>> >>> >>> >>> I am a Smalltalker. >>> >>> But in the past few months i have been running with the Haskellers. >>> >>> The Haskellers hate state. >>> >>> This seemed strange at first because as a Smalltalker i love(d) state. >>> State iswas my friend. >>> >>> 90% of my life as a Smalltalker is state wrangling. I am a state >>> herder. >>> >>> The debugger is my staff I use to whack the state. And TestCase is my >>> sheep dog. >>> >>> But to the Haskellers >>> >>> state is >>> >>> the evil trinity >>> >>> of >>> >>> satan the anti christ and the false prophet >>> >>> all rolled into one. >>> >>> State is the true dev incarnation of the total catastrophe of >>> development Armageddon. >>> >>> Blood up to the bridles for hundreds of miles. Dogs and cats living >>> together. Mass hysteria. >>> >>> They say. >>> >>> I'm not sure i quite get it yet but they keep preaching on this one >>> point most of all. >>> >>> State is evil. >>> >>> You must keep all state in a Monad. As many methods/functions m as >>> possible >>> >>> must be 100% dependent on the input parameters ONLY. >>> >>> No hidden instance variables affecting the return value of m are allowed. >>> >>> The only effect m can have is to return a value. >>> >>> If all this is true then m is pure. >>> >>> And pure is good. Pure is very good. And the wind says >>> >>> very. >>> >>> So i wonder if any of you fellow >>> >>> Smalltalkers >>> >>> have thought about this at all. >>> >>> First, there are no good definitions of what is an object oriented >>> language and what is a functional language. >>> Thus, languages like C++, C#, Java are being considered object oriented. >>> But their object orientation is not the same like Smalltalkâs. >>> The same problem exists in the functional language world: Some consider >>> LISP being functional, some deny that. >>> >>> Second, for some years I am constantly seeking for âthe bestâ language >>> to solve my problems in. Alas I wasnât successful yet and donât expect >>> to be successful in the future. Every programming paradigm has its >>> strengths and weaknesses when it comes to real world problems. >>> So in my eyes it is best to know the different programming paradigms and >>> its representative languages in order to be able to choose the >>> best fitting language for your problem at hand. >>> >>> Third, there have been many attempts to create multi-paradigm languages >>> (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >>> the best characteristics. In my eyes all of them failed because what >>> always have been created is Frankensteinâs monster. When you combine >>> paradigms you will may get some advantages of all but sure you will get >>> a lot of additional complexity. >>> >>> Fourth, it has been said many times before: What makes Smalltalk so nice >>> is not only the language. Itâs the whole system: the language, duck typing, >>> the image (object world), the tools, the VM, the simplicity, the >>> elegance, â¦ And last but not least the communities around. >>> >>> Regards >>> Andreas >>> >>> PS: If you are interested in functional programming and donât like >>> static typing you should have a look at Clojure. It has some nice ideas >>> about >>> how to deal with state concurrently. >>> >>> >>> >>> Thanks >>> >>> Kjell E GodÃ¸ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (((((((((( Maybe Smalltalk should be called Statewalk >>> >>> as in yak it up fuzz ball. )))))))))) >>> >>> >>>

Aug. 1, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

On Monday, July 6, 2015, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Kjell, > > On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist(a)gmail.com > <javascript:_e(%7B%7D,'cvml','squeaklist(a)gmail.com');>> wrote: > > Thank you for the detailed reply Andreas > > > > Are there any Smalltalk packages implementing > > Category Theory based > > functional programming constructs > > for function composition like > > functors , applicatives , monads , arrows , etc ? > > > > Do people have opinions about whether or not > > these plus immutable data structures would be good for managing state > > in Smalltalk like they do it in Haskell etc? i know that monads are not > built > > into Haskell but are implemented as addons via Haskell packages. > > My Haskell friend said all you need to do functional programming is > > first class functions > > which Smalltalk Block contexts almost are except they lack their own stack? > > if you wrap a Block in a Function Object do you then get the stack > > effect so you can essentially call the Block recursively? > > > The Pharo & Squeak dialects, along with most others, now have closures, so > blocks are fully recursive. > > > i have been wondering about taking a crack at implementing these > > in Smalltalk and i wonder if it would be > > theoretically possible > > to speed them up by inlining them via the Smalltalk compiler > > > The compiler already inlines closures in a few key control messages such > as ifTrue: whileTrue: and:. > > > I recommend spending some time reading the code for the core execution > classes and the compiler, and running examples interactively to learn how > the system works. It's a fun process and well supported by the tools. > Remember that the debugger includes a meta circular interpreter for > executing the system's bytecode, and that the compiler compiles source to > bytecode in the firm of CompiledMethod instances you can inspect, decompile > and list their bytecode. > > All the questions you have above you can answer for yourself by running > examples and using the tools to observe what happens. This is a route to > mastering the system; IMNERHO the best. > > is there any tutorial? how do i do this? > > Thank you > > > Eliot (phone) > > > On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de > <javascript:_e(%7B%7D,'cvml','a.wacknitz(a)gmx.de');>> wrote: > >> >> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >> >> This is off topic. >> >> I tried to post it as a top level thread but I have become unknown. >> >> Why do you expect that? Many people here are using Smalltalk for years. >> Just because you have been silent for some time doesnât mean everybody >> will forget about you :) >> >> >> I don't know if you want this crap in here but I have decided not to wait >> for the >> >> postmaster to get back to me on the subject of becoming known. Feel free. >> >> >> >> >> >> ( Original-SUBJECT: "( picoVerse-:( what about state , is state >> really evil? ) )" ) >> >> >> >> >> >> >> I am a Smalltalker. >> >> But in the past few months i have been running with the Haskellers. >> >> The Haskellers hate state. >> >> This seemed strange at first because as a Smalltalker i love(d) state. >> State iswas my friend. >> >> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >> >> >> The debugger is my staff I use to whack the state. And TestCase is my >> sheep dog. >> >> But to the Haskellers >> >> state is >> >> the evil trinity >> >> of >> >> satan the anti christ and the false prophet >> >> all rolled into one. >> >> State is the true dev incarnation of the total catastrophe of development >> Armageddon. >> >> Blood up to the bridles for hundreds of miles. Dogs and cats living >> together. Mass hysteria. >> >> They say. >> >> I'm not sure i quite get it yet but they keep preaching on this one point >> most of all. >> >> State is evil. >> >> You must keep all state in a Monad. As many methods/functions m as >> possible >> >> must be 100% dependent on the input parameters ONLY. >> >> No hidden instance variables affecting the return value of m are allowed. >> >> The only effect m can have is to return a value. >> >> If all this is true then m is pure. >> >> And pure is good. Pure is very good. And the wind says >> >> very. >> >> So i wonder if any of you fellow >> >> Smalltalkers >> >> have thought about this at all. >> >> First, there are no good definitions of what is an object oriented >> language and what is a functional language. >> Thus, languages like C++, C#, Java are being considered object oriented. >> But their object orientation is not the same like Smalltalkâs. >> The same problem exists in the functional language world: Some consider >> LISP being functional, some deny that. >> >> Second, for some years I am constantly seeking for âthe bestâ language to >> solve my problems in. Alas I wasnât successful yet and donât expect >> to be successful in the future. Every programming paradigm has its >> strengths and weaknesses when it comes to real world problems. >> So in my eyes it is best to know the different programming paradigms and >> its representative languages in order to be able to choose the >> best fitting language for your problem at hand. >> >> Third, there have been many attempts to create multi-paradigm languages >> (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >> the best characteristics. In my eyes all of them failed because what >> always have been created is Frankensteinâs monster. When you combine >> paradigms you will may get some advantages of all but sure you will get a >> lot of additional complexity. >> >> Fourth, it has been said many times before: What makes Smalltalk so nice >> is not only the language. Itâs the whole system: the language, duck typing, >> the image (object world), the tools, the VM, the simplicity, the >> elegance, â¦ And last but not least the communities around. >> >> Regards >> Andreas >> >> PS: If you are interested in functional programming and donât like static >> typing you should have a look at Clojure. It has some nice ideas about >> how to deal with state concurrently. >> >> >> >> Thanks >> >> Kjell E GodÃ¸ >> >> >> >> >> >> >> >> >> >> (((((((((( Maybe Smalltalk should be called Statewalk >> >> as in yak it up fuzz ball. )))))))))) >> >> >>

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by stepharo

Yes I think that we should do something to make sure that we understand that this is a button. Stef

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Esteban Lorenzano

> On 01 Aug 2015, at 13:25, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > Hello, > > Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window. but they are buttons, then they should look like one. alsoâ¦ âVariablesâ (button or whatever) there just do not make sense (since is a âclassâ related action)â¦ it increases confusion instead solving a problem. we need a better general approach for those actions, maybe a toolbar or something like thatâ¦ but as it is now it does not work. Esteban > > I agree about the class side button. > > Franck > > Date: Sat, 1 Aug 2015 12:26:02 +0200 > From: i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com> > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? > > Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either. > And since everyone is used to it by now nobody will want to change it. :) > > > On Sat, Aug 1, 2015 at 12:21 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > Hi, > > why are the new nautilus buttons not buttons? > > <2015-08-01_122023.png> > â > They look like labels which is confusing. > > Peter

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Peter UhnÃ¡k

Well my point is that if I see a button I know it will do something. If I see a label I will ignore it, because it's just a label. I don't think it's a good UX to make it clickable. (The only reason why Class side can get away with it is because there's checkbox next to it). On Sat, Aug 1, 2015 at 1:25 PM, Franck Warlouzet < franck.warlouzet(a)hotmail.fr> wrote: > Hello, > > Yes it looks a little bit 'lite' but we did not want to have 2 buttons > with the same look but two different kinds of actions. Hierarchy button > changes the window itself and variable and scoped open a new menu or > window. > > I agree about the class side button. > > Franck > > ------------------------------ > Date: Sat, 1 Aug 2015 12:26:02 +0200 > From: i.uhnak(a)gmail.com > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? > > > Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't > entirely consistent either. > And since everyone is used to it by now nobody will want to change it. :) > > > On Sat, Aug 1, 2015 at 12:21 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > why are the new nautilus buttons not buttons? > > > â > They look like labels which is confusing. > > Peter > > >

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Franck Warlouzet

Hello, Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window. I agree about the class side button. Franck Date: Sat, 1 Aug 2015 12:26:02 +0200 From: i.uhnak(a)gmail.com To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either.And since everyone is used to it by now nobody will want to change it. :) On Sat, Aug 1, 2015 at 12:21 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: Hi, why are the new nautilus buttons not buttons? â They look like labels which is confusing. Peter

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Peter UhnÃ¡k

Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either. And since everyone is used to it by now nobody will want to change it. :) On Sat, Aug 1, 2015 at 12:21 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > why are the new nautilus buttons not buttons? > > > â > They look like labels which is confusing. > > Peter >

Aug. 1, 2015

Nautilus new buttons not buttons?

by Peter UhnÃ¡k

Hi, why are the new nautilus buttons not buttons? â They look like labels which is confusing. Peter

Aug. 1, 2015

Re: [Pharo-dev] cleanup rubric

by stepharo

Yes the situation with rubric is a real mess :( Ideally I would like to throw away text and rub altogether. Now I would like to understand what is a good path that minimise duplication. In addition I do not understand why certain class extensions are not the same in both packages. So I will try to get some time to read code and come with a list of actions. If you have some ideas I'm interested. Stef >> Maybe I am wrong, but it looks like there are many >> classes and code in rubric that are the same as in the old Text classes. > > Yes never said that Rubric is the future. He just improved a bit > >> Rub is used in GT and now in the Core image. Shouldn't we clean this up >> before it used everywhere? >> >> Some examples: >> >> All TextLink classes looks the same (TextClassLink <-> RubTextClassLink) >> >> MorphAnnouncement subclass: #RubMorphAnnouncement >> RubMorphAnnouncment adds nothing >> >> FindReplaceService <-> RubFindReplaceService >> They look very similar, I don't understand why so much code is >> just the same in both, why not extract that into a base class? >> (and the same for RubFindReplaceDialogWindow/ FindReplaceDialogWindow >> and some many too) >> >> RubEditingState / EditingState. >> >> What this makes it even worse, Rubs class comment doesn't indicate how >> they differ from the old other one. > True. >> It is really difficult to understand, >> - which (Rub)classes were created just because the old TextApi has >> them, but aren't actually used in the current Rubric framework. >> - wich classes are used but could be replaced with the existing one >> (TextLink for example) >> - which classes had to be changed, and therefore only the Rub-classes >> can work with rubric. >> - which classes are similiar named like the old Text classes and >> share some code but may work >> totally different. >> >> (For example TextEditor vs. RubTextEditor there are some methods in >> both that aren't used >> anywhere, it looks like RubTextEditor is just >> - a copy from TextEditor, >> - changed where it was needed >> - unchanged otherwise > Yes. I think that alain did it like that. He just wanted to offer some > behavior for the Moosers. >> Rubric really adds some great new things and if you look at where it >> is used, it >> is really a great step forward, but the code is in a bad state. >> This needs to be cleaned up. > Definitively. > Nicolai > do you have a list of actions? > because I would like to do some of them. > We could remove the duplicate. This is what we started to do with > PluggableTextMorph. > >

Aug. 1, 2015