[Packages] Split-Join in development universe etc
Locked
12
12
Re: [Packages] Split-Join in development universe etc
 
|
Hi!
> El 8/9/07 5:32 AM, "Göran Krampe" <[hidden email]> escribió: > >> I still think #removeAll (my own pet Collection >> addition that got shot down by some people a few years back) > > Göran : > > Nice see you again on list. I am here - just had vacation and a longish ADSL breakdown. :) > If you have Collection additions not in current 3.10, I wish know. > I could consult with Ralph and maybe have into Squeak again. > > I bet several masters have nice things on his computers unknown to many of > us, is time to show, discuss and share. Will see if I can dig it out - it was rather trivial - an abstract #removeAll method in Collection with concrete implementations in subclasses - an OrderedCollection for example can just drop the Array. This allows to easily remove all elements and maintaining identity of the collection instead of creating a new one. As I said, trivial. regards, Göran |
Re: [Packages] Split-Join in development universe etc
|
|
In reply to this post by Andreas.Raab
On Aug 9, 2007, at 12:11 AM, Andreas Raab wrote: >> Wanting code to be concise is code smell? If you meant adding a >> method to collections that only joins strings is a code smell then >> ok, but otherwise.... well I strongly disagree to say the least. > > Concise can mean different things. If it means a bloated collection > interface to accommodate every single person's pet extensions then > I think that stinks. And that's exactly what we've seen over the > last years - ever-increasing amounts of partially overlapping > functionality none of which is widely used and only makes it more > difficult to find the few truly useful methods. Split for example, > is for all practical purposes completely subsumed by findTokens: so > why do we need split in addition to findTokens? Agreed. I was actually thinking of the larger design issue here - the circumstances under which #join: would be useful. Let's look at a typical example: You've got an array of names, that you need to join into a comma- separated list. If this list is part of some larger string, you're building it by writing into a WriteStream, or you should be, so #do:separatedBy: will serve you better than #join:. Ah but wait, you actually want to display this list on a web page, so you've got the canvas APi in Seaside, and there is no stream. In this case the idiomatic Smalltalk would be: String streamContents: [:stream | names do: [:ea | stream nextPutAll: ea] separatedBy: [stream nextPutAll: ', ']. Pretty verbose. You need #join:, because you're passing this list around to a bunch of different objects, and there's not even a single class where you can stick this inside a method called #listOfNames. Well, that's a code smell. You've got some very generic data types here - an array of strings. But that data means something, and the knowledge of what it means and the code for processing it is spread out all over the place. That array of strings is begging to be turned into an object that encapsulates the meaning. Once that's done, you can stick that verbose code to join names inside a method and forget about it. If at some point you want to change it to semicolons instead of commas, you've got one place to change, instead of many senders of #join:. That's not the only possible use of #join: of course. But I think a design that causes you to process collections of strings a lot - enough that you want it to be concise - is a warning sign. Colin |
Re: [Packages] Split-Join in development universe etc
|
|
In reply to this post by keith1y
On 8/9/07, Keith Hodges <[hidden email]> wrote:
I think it could do if you are ripping things out, since it might become And here is what makes me nervous (and maybe others as well): I have read the "Smalltalk Best Practice Patterns" and I try to draw a lot from the code in the image that I feel is elegant and Smalltalk style. And I have not felt this pain of not having a Null object. Maybe I haven't worked with enough different domains yet, or maybe this is something that just doesn't come up that much when coding in Smalltalk style. So if we put this in then maybe someone not fully mentally integrated into the "Smalltalk way" walks in, starts ripping things out all over the place and before you know it we have Objective-C with a little mouse at the top. I don't see a problem with there being a NullObject package out there for people who do need it, or just want to use it in their code. But why does this need to be in the main image? You are talking about ripping things out of the core and replacing it with this, but keep in mind some of the people who have worked on this code. They apparently didn't see the need so we shouldn't be so quick to just assume they didn't know what they were doing. That's not to say that what they did can never be replaced, but it just takes more thought IMO then simply making a new package out there that people can "opt in". Just a little dig at the process that has continued to demonstrate that Begging your pardon, but isn't pronouncing something you happen to like as an "innovation" a bit presumptuous? :) Innovations have and do happen in Squeak. But to get people on your side you have to prove it's worth the risk. Make an image with your Null object and replace the things you think should be replaced and then come back and show how it runs faster/is less code/is easier to maintain/whatever and maybe people will start getting on board. As a suggestion for 3.11+ my proposal is to provide the tool for users I'm a little bit confused by all this. Why does it need to be 3.11 images? What is wrong with Damien's approach of "value add" prepackaged images? |
Re: [Packages] Split-Join in development universe etc
|
|
> > Just a little dig at the process that has continued to demonstrate that
> > democracy doesn't seem to work in terms of pushing innovations, but > > appears to favour the status quo > > Begging your pardon, but isn't pronouncing something you happen to like as > an "innovation" a bit presumptuous? :) Irrespective of the quality of the innovation, changes to the core will always be slower in a democracy than a dictatorship. Compare with the introduction of brace syntax. Before brace syntax, I don't remember feeling all that much pain. I just did OrderedCollection new add:;add:;add;yourself. Certainly idiomatic Smalltalk. Can you imagine if Keith had proposed adding brace syntax today? When Squeak was a benevolent dictatorship, brace syntax just showed up in the update stream. No discussion; just announcement. We're missing the authority to effect that kind of change. Note too that Squeak Central probably judged that an incremental (pink plane) kind of change. I'm not sure there is much that can be done here. Changes by Alan, Ted, or Dan effectively *were* Smalltalk because we trust and follow. >From others, not as much. |
|
|
In reply to this post by Jason Johnson-5
>
> > So if we put this in then maybe someone not fully mentally integrated > into the "Smalltalk way" walks in, starts ripping things out all over > the place and before you know it we have Objective-C with a little > mouse at the top. If someone wants to do this then let em, its an open source project, if it works then great, if not then good luck to them. Its not our job to be the censors as to what someone may or may not do with squeak in the future. > I don't see a problem with there being a NullObject package out there > for people who do need it, or just want to use it in their code. But > why does this need to be in the main image? Null is in effect a language feature. Language features belong in the core. If a language feature is not in the core than it is not going to be widely usable, and it is certainly not going to be usable to help tidy the core. All I am saying is that I have looked at tidying things on occasion and I have thought that having 'null' would be useful, but its not there and the option is not available. > You are talking about ripping things out of the core and replacing > it with this, but keep in mind some of the people who have worked on > this code. Yes they have worked on this code, by putting it in, building it up, increasing the size. Pulling in the belt a few notches requires different skills and perhaps additional language features might help. ... > That's not to say that what they did can never be replaced, but it > just takes more thought IMO then simply making a new package out there > that people can "opt in". Yes it takes more thought to refactor and tidy up that it did to put it in in the first place, there are often more factors to be considered. Having a bigger armory of techniques is not a bad thing. > > Just a little dig at the process that has continued to demonstrate > that > democracy doesn't seem to work in terms of pushing innovations, but > appears to favour the status quo > > > Begging your pardon, but isn't pronouncing something you happen to > like as an "innovation" a bit presumptuous? :) The use of innovations in that sentence is not referring to anything specific, its a general point, so I am not pronouncing anything. > Innovations have and do happen in Squeak. But to get people on your > side you have to prove it's worth the risk. Make an image with your > Null object and replace the things you think should be replaced and > then come back and show how it runs faster/is less code/is easier to > maintain/whatever and maybe people will start getting on board. This is pitting abstract versus concrete thinking. Adding a language feature is an abstract concept, and provides benefits in terms of the abstractions available for thinking about the problem etc. Concrete thinking is demanding stats before the fact. > I'm a little bit confused by all this. Why does it need to be 3.11 > images? What is wrong with Damien's approach of "value add" > prepackaged images? 3.11 is simpy a name given to a nominated starting point upon which damien can build whatever he wishes. I am only talking about one final product, with a process for getting there, which involves having a number of "fix this or that" branches Keith |
Re: [Packages] Split-Join in development universe etc
|
|
In reply to this post by David Mitchell-10
On 8/9/07, David Mitchell <[hidden email]> wrote:
> > Irrespective of the quality of the innovation, changes to the core > will always be slower in a democracy than a dictatorship. I wasn't talking about the quality of anything. I was talking about the word "innovation". I rechecked the meaning of the word since I seem to see some different uses for it then I expected: innovative adjective 1. ahead of the times; "the advanced teaching methods"; "had advanced views on the subject"; "a forward-looking corporation"; "is British industry innovative enough?" [syn: advanced] 2. being or producing something like nothing done or experienced or created before; "stylistically innovative works"; "innovative members of the artistic community"; "a mind so innovational, so original" This feels to me like one of those things you can pronounce about your own things, someone else has to do it for it to be meaningful. > Compare with the introduction of brace syntax. > > Before brace syntax, I don't remember feeling all that much pain. I > just did OrderedCollection new add:;add:;add;yourself. Certainly > idiomatic Smalltalk. > > Can you imagine if Keith had proposed adding brace syntax today? When > Squeak was a benevolent dictatorship, brace syntax just showed up in > the update stream. No discussion; just announcement. > > We're missing the authority to effect that kind of change. Note too > that Squeak Central probably judged that an incremental (pink plane) > kind of change. I'm not sure there is much that can be done here. > Changes by Alan, Ted, or Dan effectively *were* Smalltalk because we > trust and follow. > > >From others, not as much. This is a good point, but I do see things still coming in (e.g. Traits). |
Re: [Packages] Split-Join in development universe etc
|
|
On 8/9/07, Jason Johnson <[hidden email]> wrote:
> On 8/9/07, David Mitchell <[hidden email]> wrote: > > *Editing a very stupid typo > This feels to me like one of those things you *can't* pronounce about your > own things, someone else has to do it for it to be meaningful. |
Re: [Packages] Split-Join in development universe etc
|
|
In reply to this post by keith1y
On 8/9/07, Keith Hodges <[hidden email]> wrote:
> No one is stopping them. From doing it to their own image or fork. But to the base image? Yes it takes more thought to refactor and tidy up that it did to put it To a point. But not all techniques fit. I think you would agree that e.g. pointers are a technique we don't need. I mean by this that simply saying "this is another technique" isn't a get in free card. It still has be accepted by the right people, and if it isn't that isn't necessarily a failing of the community. I still don't understand the problem with having this a package and let people use it that want it? Ok, so they can't use it on the Kernel, but most Squeak work done is in external projects, not the Kernel. The use of innovations in that sentence is not referring to anything Then what innovations did you have in mind that were rejected? This is pitting abstract versus concrete thinking. Adding a language No, I'm talking about what works. Put the thing in your own personal image and use abstract thinking to make the image better and then you have something concrete to show people to get adoption. But is it possible that you are still seeing things through the lens of your previous language experience? Is it possible that the Null pattern is normally done some other way in Smalltalk and therefor isn't the hammer it was in Objective-C? I see a lot of places I feel that I could make more concise/clear code if we had Haskell/Erlang style pattern matching for functions, but that's not how Smalltalk works. Smalltalk has a Smalltalk way to solve that ( e.g. double dispatch). I would search out the Smalltalk way before trying to force pattern matching into the language. |
Re: [Packages] Split-Join in development universe etc
|
|
In reply to this post by Jason Johnson-5
Keith maybe is right.
He could have some better of current Squeak. My point is community need play in teams. I seeing signs of Anarchy. Eras ago I send a mail about the "Big Bang Effect" In the beginning, only Squeak exists. Today, we have some forks diverging (Scratch, Sophie, Croquet, OLPC, maybe others) If we start forking packages I sorry we end like the last days on Earth. A dark sky with fewer stars. We don't have a dictator today and hope no Squeaker dream of become one. We elect a Board. It's time the Board awake of his long siesta and do decisions. Or people could not vote any of current members next time. Edgar |
Re: [Packages] Split-Join in development universe etc
|
|
In reply to this post by Andreas.Raab
On 8/9/07, Andreas Raab <[hidden email]> wrote:
> It's really just strings. You're getting confused by the (sorry to say > that) poorly written code. Well, to be honest I had not looked at the code until you said this. I based my comments on the discussion we had some time back about how this should work. That's why I asked Keith at the beginning if this was the same package I thought it was. >It uses <SequenceableCollection> joinUsing: > <delimiter> which looks very general at first glance but once you dig > into it you'll notice that it really ought to be <delimiter> join: > <Collection> and that really only String is a meaningful delimiter here. > The implementation as it is creates a lot of clutter by doing it the > other way around and then (needlessly) double-dispatching into Character > and String. Besides which the code is very poorly formatted and not > documented at all(there isn't even a single comment anywhere despite > some highly unusual patterns). Not the kind of stuff I like to see in > the kernel. Well, I must admit I was frustrated that I can't see the changes from Monticello, I have to actually load it, and then open a change set viewer to figure out what happened. But the first method I looked at did in fact have a comment. :) I'm also a bit confused about the format. If you don't like the formatting can't you have it on "pretty print" and always get the same formatting always? What we originally discussed about how to do this was that the join methods would use double dispatch so that they could potentially join any "delimiter" with any collection. I'm not surprised that only Char, String and Array have been implemented so far (note: one of the tests has an example of joining one array with another array). But other then these nit-picks I'll take your word for it. I just did a quick scan over the change set to see if what I expected was there, I didn't try to judge the code quality. > Concise can mean different things. To me it means saying something clearly but with no so many words. In other words: Haskell is very concise. Perl is terse, not concise. >If it means a bloated collection > interface to accommodate every single person's pet extensions then I > think that stinks. I agree with you. I'm a bit of a minimalist myself. >And that's exactly what we've seen over the last > years - ever-increasing amounts of partially overlapping functionality > none of which is widely used and only makes it more difficult to find > the few truly useful methods. Well that is certainly unfortunate. The code could certainly use a clean up. But some things are handy. Like for example, one can already tell if a collection is empty with "size == 0", but it's still handy to use #isEmpty, no? :) >Split for example, is for all practical > purposes completely subsumed by findTokens: so why do we need split in > addition to findTokens? |
Re: [Packages] Split-Join in development universe etc
|
|
Jason Johnson wrote:
> Well, I must admit I was frustrated that I can't see the changes from > Monticello, I have to actually load it, and then open a change set > viewer to figure out what happened. Try this: * Save the MCZ to a directory * Add that directory as repository to MCZ * Open it, navigate to the MCZ * Choose "Changes" from the repo browser This will show the diff of the MCZ in question to whatever is in your image. > But the first method I looked at did in fact have a comment. :) Where? I just double-checked and can't find any comments in join-kph.2.mcz (the version I'm looking at). > I'm also a bit confused about the format. If you don't like the > formatting can't you have it on "pretty print" and always get the same > formatting always? I *never* do that. It's a lossy transformation of source code. Formatting reveals intent often just as strongly as a comments. >> If it means a bloated collection >> interface to accommodate every single person's pet extensions then I >> think that stinks. > > I agree with you. I'm a bit of a minimalist myself. I'm not (at least I don't think of myself as being one). To me, the most important questions are: How useful is this extension in general? How applicable to other domains? How quickly come examples for it to mind? How much would this extension simplify the resulting code? And I can't say that for split/join I find that the benefits outweigh the added complexity. Others may disagree of course. Cheers, - Andreas |
Re: [Packages] Split-Join in development universe etc
|
|
On 8/10/07, Andreas Raab <[hidden email]> wrote:
> > Try this: > * Save the MCZ to a directory > * Add that directory as repository to MCZ > * Open it, navigate to the MCZ > * Choose "Changes" from the repo browser > This will show the diff of the MCZ in question to whatever is in your image. Odd, I did that and I get the same thing as when I use the Squeak source repo directly: All I see is a preamble for the installer to load from a bug report. > Where? I just double-checked and can't find any comments in > join-kph.2.mcz (the version I'm looking at). Hrm, well I loaded join-kph.2.mcz (due to the problem mentioned earlier) and I see several: SequencableCollection>>joinUsing: SequencableCollection>>joinUsing:last: SequencableCollection>>splitOn: So 3 out of the first 4 in the change set. But I was just pointing this out earlier as a joke. > I *never* do that. It's a lossy transformation of source code. > Formatting reveals intent often just as strongly as a comments. Ah. Well I never do it either, but saw on a webcast someone using that, so I thought maybe it would be an ok solution if you really don't like the way someone formats code. I personally find that one's formatting is largely affected by the languages they used previously and the formatting conventions from there. I didn't like the Smalltalk formatting at first, but I am moving more that direction. But as you say, I also use formatting to highlight things and I see others do it as well. > I'm not (at least I don't think of myself as being one). To me, the most > important questions are: How useful is this extension in general? How > applicable to other domains? How quickly come examples for it to mind? > How much would this extension simplify the resulting code? That's kind of what I meant by "a minimalist". :) I agree 100%. > And I can't > say that for split/join I find that the benefits outweigh the added > complexity. Others may disagree of course. > > Cheers, > - Andreas And here lies the root of the question. I thought it might be a good trade off, but perhaps it would be better a special "string enhancing" package or something, as that stuff would most be used in a text manipulating or script domain I think. |
|
|
>
> I personally find that one's formatting is largely affected by the > languages they used previously and the formatting conventions from > there. I didn't like the Smalltalk formatting at first, but I am > Indeed, my formatting is influenced by the fact that the previous language/environment I used was ST/X which has a great formatter. Keith |
Re: [Packages] Split-Join in development universe etc
|
|
I always use a formatter on my own code. Find one that works well for
90% of my methods. Format before saving. If anything jumps where I wasn't expecting, it might be an error. I would really like on that follows the rules in Beck's Smalltalk Best Practice Patterns. Chris Muller commented to me that he had such a beast. Chris, is it something you can share? On 8/10/07, Keith Hodges <[hidden email]> wrote: > > > > I personally find that one's formatting is largely affected by the > > languages they used previously and the formatting conventions from > > there. I didn't like the Smalltalk formatting at first, but I am > > > Indeed, my formatting is influenced by the fact that the previous > language/environment I used was ST/X which has a great formatter. > > Keith > > > > |
Re: [Packages] Split-Join in development universe etc
|
|
In reply to this post by Jason Johnson-5
"Jason Johnson" <[hidden email]> writes:
> Wouldn't it be best to get this fix loaded into the Montecello repository as > a proper change, so that the Universe just has to point at the new version? I have the same question. Why not post a Monticello file and link to it? Or if Monticello cannot handle it (why?), link it to a changeset? In the world of computer representations, it is often nice to use a representation whose power is limited. For example, regular expressions are not Turing complete, but there are all kinds of convenient things about regexes. You can test a specific string in linear time. You can test a regex itself for whether it matches nothing at all... or if it matches everything. You can't do these things with an arbitrary program in a Turing-complete language, because the representation is too powerful. The same goes for package formats. I would like us to use a package format where basic intuitive properties hold [1]. For example, you can load and unload a package and get back to the original state. As another example, if you have a file with a package in it, then the file is all you need to load it. You should not need the file, plus an Internet connection, to load the package. As a case in point, when I release a stable universe, I normally gather all of the package files and put them in one archival location. The main reason is that web sites come and go, but I can control my own archive pretty well. Obviously, if your package file is scanning the Internet at load time, then this archiving is less effective. > Personally I see Monticello as a change repository like CVS, SVN, etc. (but > better), and Universes as the "apt-get" system debian has. I don't think > the apt-get system automatically picks anything up, it only gets what has > been configured for the set it is working on (e.g. Stable, Unstable, etc.). > Now those sets may be programatically updated, but the apt-get system itself > doesn't (afaik anyway) and imo shouldn't do it. That is my view as well. I am very happy to see Monticello mcz's emerging as a package format. I am also very happy that people like Keith are going through all the corner cases of making it work in Squeak, because even basic loading and unloading is not easy in Squeak! Lex [1] To split a hair, I know these properties are unrealistic ideals. It is still nice to get as close as possible. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |