Stream >> <<
Locked
1234
... 6
1234
... 6
 
|
Hello!
In Pharo 7.0.4, Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] >>> #($1 $0 $1 $0 10 '10') Bug or feature? Herby |
|
|
Herby,
It's a feature. ;-) << sends putOn: message to the non-collection args. Integer>>#putOn: aStream aStream isBinary ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each ] ] ifFalse: [ self asString putOn: aStream ] String>>#putOn: aStream aStream nextPutAll: self > On 10 Sep 2019, at 11:27, Herby Vojčík <[hidden email]> wrote: > > Hello! > > In Pharo 7.0.4, > > Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] > > >>> #($1 $0 $1 $0 10 '10') > > Bug or feature? > > Herby > |
|
|
In reply to this post by Herby Vojčík
I think it's fair to say that #<< *is* a bug. There does not seem to be any coherent description of what it means. It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or* something else, in some confusing ways. CommandLineHandler #nextPutAll: (sent somewhere else) Integer left shift (someone has been smoking too much C++) NonInteractiveTranscript #show: = locked #print: SocketStream #putOn: (which may itself act like #nextPut:, #nextPutAll:, #print, put elements sans separators, or something else) Stream #putOn: (see above) WriteStream either #nextPutAll: or #putOn: Transcript #show: = locked #print: ThreadSafeTranscript #show: = locked #print: VTermOutputDriver #putOn: VTermOutputDriver2 #asString then #nextPutAll: ZnEncodedWriteStream #nextPutAll: ZnHtmlOutputStream #asString then #nextPutAll: SequenceableCollection class #streamContents: As was once said about PL/I, #<< fills a much-needed gap. When I see #print:, or #nextPut:, or #nextPutAll:, I know what to expect. When I see #putOn:, I have in general no idea what will happen. And when I see << it is worse. One point of << is to imitate C++'s composition of outputs. That might work, too, if only there were some agreement about what #nextPutAll: returns. There is not. It might return the receiver. It might return some other stream related to the receiver. It might even return the collection argument. So when you see a << b << c in general you not only do not have a clue what (a) is going to do with (b) but you have no idea what object the message << c will be sent to. Now let's see if we can puzzle out what Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] does. The output will be going to a WriteStream. aWriteStream << anInteger is not, but is like, aWriteStream print: anInteger. So we add $1 and $0. aWriteStream << aString reduces to aWriteStream nextPutAll: aString. So we add $1 and $0. aWriteStream on anArray << anotherArray reduces to aWriteStream nextPutAll: anotherArray. So we add 10 and '10'. Thus the result we get is #($1 $0 $1 $0 10 '10'). What result we should *expect* from this muddle I cannot say. If, on the other hand, you wrote explicitly Array streamContents: [:stream | stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')] you would have an easy time figuring out what to expect. By the way, there is no standard definition of #show:, but in other Smalltalk systems it's usually a variant of #nextPutAll:, not a variant of #print:. There's no denying that locked output is useful to have, but #show: is not perhaps the best name for it. |
|
|
Development happens in Pharo 8 first, with possible back ports if really necessary.
The last relevant change was the following: https://github.com/pharo-project/pharo/pull/2698 > On 10 Sep 2019, at 14:54, Richard O'Keefe <[hidden email]> wrote: > > I think it's fair to say that #<< *is* a bug. > There does not seem to be any coherent description of what it means. > It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or* > something else, in some confusing ways. > CommandLineHandler #nextPutAll: (sent somewhere else) > Integer left shift (someone has been smoking too much C++) > NonInteractiveTranscript #show: = locked #print: > SocketStream #putOn: (which may itself act like > #nextPut:, #nextPutAll:, #print, > put elements sans separators, or > something else) > Stream #putOn: (see above) > WriteStream either #nextPutAll: or #putOn: > Transcript #show: = locked #print: > ThreadSafeTranscript #show: = locked #print: > VTermOutputDriver #putOn: > VTermOutputDriver2 #asString then #nextPutAll: > ZnEncodedWriteStream #nextPutAll: > ZnHtmlOutputStream #asString then #nextPutAll: > SequenceableCollection class #streamContents: > > As was once said about PL/I, #<< fills a much-needed gap. > When I see #print:, or #nextPut:, or #nextPutAll:, I know > what to expect. When I see #putOn:, I have in general no > idea what will happen. And when I see << it is worse. > > One point of << is to imitate C++'s composition of outputs. > That might work, too, if only there were some agreement > about what #nextPutAll: returns. There is not. It might > return the receiver. It might return some other stream > related to the receiver. It might even return the collection > argument. So when you see > a << b << c > in general you not only do not have a clue what (a) is going > to do with (b) but you have no idea what object the message > << c will be sent to. > > Now let's see if we can puzzle out what > Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] > does. > The output will be going to a WriteStream. > aWriteStream << anInteger > is not, but is like, aWriteStream print: anInteger. > So we add $1 and $0. > aWriteStream << aString > reduces to aWriteStream nextPutAll: aString. > So we add $1 and $0. > aWriteStream on anArray << anotherArray > reduces to aWriteStream nextPutAll: anotherArray. > So we add 10 and '10'. > Thus the result we get is > #($1 $0 $1 $0 10 '10'). > What result we should *expect* from this muddle I cannot say. > > If, on the other hand, you wrote explicitly > Array streamContents: [:stream | > stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')] > you would have an easy time figuring out what to expect. > > By the way, there is no standard definition of #show:, but in > other Smalltalk systems it's usually a variant of #nextPutAll:, > not a variant of #print:. There's no denying that locked output > is useful to have, but #show: is not perhaps the best name for it. > |
|
|
In reply to this post by Richard O'Keefe
On 10. 9. 2019 14:54, Richard O'Keefe wrote:
> I think it's fair to say that #<< *is* a bug. > There does not seem to be any coherent description of what it means. > It's overloaded to mean *either* #nextPut: *or* #nextPutAll: *or* > something else, in some confusing ways. > CommandLineHandler #nextPutAll: (sent somewhere else) > Integer left shift (someone has been smoking too > much C++) > NonInteractiveTranscript #show: = locked #print: > SocketStream #putOn: (which may itself act like > #nextPut:, #nextPutAll:, #print, > put elements sans separators, or > something else) > Stream #putOn: (see above) > WriteStream either #nextPutAll: or #putOn: > Transcript #show: = locked #print: > ThreadSafeTranscript #show: = locked #print: > VTermOutputDriver #putOn: > VTermOutputDriver2 #asString then #nextPutAll: > ZnEncodedWriteStream #nextPutAll: > ZnHtmlOutputStream #asString then #nextPutAll: > SequenceableCollection class #streamContents: > > As was once said about PL/I, #<< fills a much-needed gap. > When I see #print:, or #nextPut:, or #nextPutAll:, I know > what to expect. When I see #putOn:, I have in general no > idea what will happen. And when I see << it is worse. I don't think so. I have pretty coherent view of how << can work. In Amber this coherent view helped to create Silk library for DOM manipulation by treating a DOM element as a ind of a stream. Having simple thing working (<< aCollection unpack the collection, having putOn: to be able to customize how object are put on stream) can help a lot; if, things are kept consistent. > One point of << is to imitate C++'s composition of outputs. > That might work, too, if only there were some agreement > about what #nextPutAll: returns. There is not. It might > return the receiver. It might return some other stream > related to the receiver. It might even return the collection > argument. So when you see > a << b << c > in general you not only do not have a clue what (a) is going > to do with (b) but you have no idea what object the message > << c will be sent to. This is strawman. We know what str << a << b << c does if we know what is output of #<<, it has nothing to do with #nextPutAll:. And it's simple, STream >> << should return self, and we're done. > Now let's see if we can puzzle out what > Array streamContents: [ :s | s << 10 << '10' << #(10 '10') ] > does. > The output will be going to a WriteStream. > aWriteStream << anInteger > is not, but is like, aWriteStream print: anInteger. > So we add $1 and $0. > aWriteStream << aString > reduces to aWriteStream nextPutAll: aString. > So we add $1 and $0. > aWriteStream on anArray << anotherArray > reduces to aWriteStream nextPutAll: anotherArray. > So we add 10 and '10'. > Thus the result we get is > #($1 $0 $1 $0 10 '10'). > What result we should *expect* from this muddle I cannot say. #(10 '10' 10 '10') Of course. After all, I put things on Array stream, which holds objects, not a character stream. > If, on the other hand, you wrote explicitly > Array streamContents: [:stream | > stream print: 10; nextPutAll: '10'; nextPutAll: #(10 '10')] > you would have an easy time figuring out what to expect. I see nextPut[All]: as low-level put API, and print:, write: and << as high-level one. I would not combine them. I actually combine print: with write: to nice effect in Amber. Lot of code which actually export source to the disk uses combination of these two to enhance readability (IMO). For example: exportTraitDefinitionOf: aClass on: aStream "Chunk format." aStream write: 'Trait named: '; printSymbol: aClass name; lf; tab; write: 'package: '; print: aClass category; write: '!!'; lf. aClass comment ifNotEmpty: [ aStream write: '!!'; print: aClass; write: ' commentStamp!!'; lf; write: { self chunkEscape: aClass comment. '!!' }; lf ]. aStream lf As write: and << are synonyms in Amber (so they probably was in some part of Pharo history), I chose to pair print: keyword selector with write: keyword selector from the style point of view. Also, since write: is <<, I can write: a collection of pieces to put and I don't need to cascade lots of write:s. What I wanted to illustrate is, good implementation of << can be pretty useful. > By the way, there is no standard definition of #show:, but in > other Smalltalk systems it's usually a variant of #nextPutAll:, > not a variant of #print:. There's no denying that locked output > is useful to have, but #show: is not perhaps the best name for it. Herby |
|
|
In reply to this post by Sven Van Caekenberghe-2
On 10. 9. 2019 15:20, Sven Van Caekenberghe wrote:
> Development happens in Pharo 8 first, with possible back ports if really necessary. > > The last relevant change was the following: > > https://github.com/pharo-project/pharo/pull/2698 > That's a very nice change, indeed. Thank you. But there's still one catch. I looked, and in Pharo 8 branch, this is still the active implementation: WriteStream >> << anObject [ "Write anObject to the receiver, dispatching using #putOn: This is a shortcut for both nextPut: and nextPutAll: since anObject can be both the element type of the receiver as well as a collection of those elements. No further conversions of anObject are applied. This is an optimisation. Return self to accomodate chaining." anObject class == collection class ifTrue: [ self nextPutAll: anObject ] ifFalse: [ anObject putOn: self ] ] It is wrong to shortcut putOn: double dispatch based on anObject class == collection class. I strongly believe this test should pass: testPutDiverseNestedSequences | array otherSequenceable higherOrderArray higherOrderSequenceable | array := Array with: 1 with: 2 with: 3. otherSequenceable := OrderedCollection with: 1 with: 2 with: 3. higherOrderArray := Array with: array with: otherSequenceable. higherOrderSequenceable := OrderedCollection with: array with: otherSequenceable. result := Array streamContents: [ :s | s << array << otherSequenceable << higherOrderArray << higherOrderSequenceable ]. self assert: result equals: #( 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 ) If I guess correctly, based on mere implemetation detail of which class holds the 1 2 3, some of them are not unnested. I understand how that optimization is needed in case a string is put on character stream, double dispatching every character is insane. But so is shortcutting Array is Array-based stream. Maybe the optimization should have additional anObject isString test (in case of string, the counterexample cannot be created, because they cannot be nested). Or there should be additional double dispatch via nextPutString:, if string-based streams have their hierarchy. You know the codebase better. Unless it is already solved by some other twist. Thanks, Herby |
|
|
In reply to this post by Herby Vojčík
It is good that you have a coherent idea of how << can work.
The question I was addressing is how << *DOES* work in Pharo. Having simple things working, if they are kept consistent, is indeed good. The problem is that in Pharo 7 they are NOT consistent, and << does NOT work consistently, because there are occasions when << does ^something nextPutAll: something else and nextPutAll: returns something else. I am grateful for the link to the changes to Pharo 8. That's a massive simplification and improvement. There is some way to go yet. The very first thing that should be done is to write down what the *semantics* of #<< is supposed to be, and then to ensure it is implemented that way. Let's look at the chunk example. exportTraitDefinitionOf: aClass on: aStream "Chunk format." aStream nextPutAll: 'Trait named: '; nextPutAll: aClass name; cr; tab; nextPutAll: 'package: '; print: aClass category; nextPutAll: '!!'; cr. aClass comment isEmpty ifFalse: [ aStream nextPutAll: '!!'; print: aClass; nextPutAll: 'commentStamp!!'; cr; nextPutAll: aClass category withDelimiter: $!; nextPutAll: '!!'; cr]. aStream cr. With the exception of #nextPutAll:withDelimiter:, this is completely standard and portable. If I am willing to do something nonstandard, aStream format: 'Trait named: {s}{n}{t}package: {p}{n}' with: aClass name with: aClass category. aClass comment isEmpty ifFalse: [ aStream format: '!!{p} commentStamp!!{n}{D$!}!!{n}' with: aClass with: aClass comment]. aClass format: '{n}. #write: really does not seem to be any improvement over #nextPutAll:. For what it's worth, GNU Smalltalk also has #<<, which it defines to be equivalent to #displayOn:, if memory serves me correctly. It has never been clear to me what the use case for #write: is. In Pharo 7, for streams it is the same as #putOn: except for the result. Neither of them is in any interesting way "higher level" than #nextPut: or #nextPutAll:, merely less informative. |
|
|
On 11. 9. 2019 3:23, Richard O'Keefe wrote:
> It is good that you have a coherent idea of how << can work. After the changes sent by Sven, Pharo 8 seems to have the exactly same idea. IMNSHO. > The question I was addressing is how << *DOES* work in Pharo. > Having simple things working, if they are kept consistent, > is indeed good. The problem is that in Pharo 7 they are NOT > consistent, and << does NOT work consistently, because there > are occasions when << does ^something nextPutAll: something else > and nextPutAll: returns something else. Bug. '^' should not have been there. > I am grateful for the link to the changes to Pharo 8. > That's a massive simplification and improvement. > There is some way to go yet. Actually, from my PoV, just the fix I posted. The rest seems correct. > The very first thing that should be done is to write down > what the *semantics* of #<< is supposed to be, and then to > ensure it is implemented that way. > > Let's look at the chunk example. > > exportTraitDefinitionOf: aClass on: aStream > "Chunk format." > aStream > nextPutAll: 'Trait named: '; nextPutAll: aClass name; cr; The devil is in the details. Why you changed `printSymbol: aClass name` for `nextPutAll: aClass name`? Now it outputs things incorrectly. You should have changed it for `print: aClass name asSymbol` And this is precisely that distinction between low-level nextPutAll: and high-level write: / << / print:. > tab; nextPutAll: 'package: '; print: aClass category; nextPutAll: > '!!'; cr. > aClass comment isEmpty ifFalse: [ > aStream > nextPutAll: '!!'; print: aClass; nextPutAll: 'commentStamp!!'; cr; > nextPutAll: aClass category withDelimiter: $!; nextPutAll: '!!'; cr]. > aStream cr. > > With the exception of #nextPutAll:withDelimiter:, this is completely > standard and portable. If I am willing to do something nonstandard, > > aStream format: 'Trait named: {s}{n}{t}package: {p}{n}' > with: aClass name with: aClass category. > aClass comment isEmpty ifFalse: [ > aStream format: '!!{p} commentStamp!!{n}{D$!}!!{n}' > with: aClass with: aClass comment]. > aClass format: '{n}. > > #write: really does not seem to be any improvement over #nextPutAll:. Will post. > For what it's worth, GNU Smalltalk also has #<<, which it defines > to be equivalent to #displayOn:, if memory serves me correctly. > It has never been clear to me what the use case for #write: is. > In Pharo 7, for streams it is the same as #putOn: except for the > result. Neither of them is in any interesting way "higher > level" than #nextPut: or #nextPutAll:, merely less informative. |
|
|
On 11. 9. 2019 11:46, Herby Vojčík wrote:
> On 11. 9. 2019 3:23, Richard O'Keefe wrote: >> #write: really does not seem to be any improvement over #nextPutAll:. > > Will post. Actually, I won't. I don't care any more. I found Contributor Covenant-derived Code of Conduct was added to Pharo, three months ago. This is unacceptable under any circumstances. Have fun in your woke hell. Herby |
Re: Stream >> <<
|
|
On 11/09/19 9:14 a. m., Herby Vojčík wrote: > On 11. 9. 2019 11:46, Herby Vojčík wrote: >> On 11. 9. 2019 3:23, Richard O'Keefe wrote: >>> #write: really does not seem to be any improvement over #nextPutAll:. >> >> Will post. > > Actually, I won't. I don't care any more. > > I found Contributor Covenant-derived Code of Conduct was added to > Pharo, three months ago. This is unacceptable under any circumstances. > > Have fun in your woke hell. > > Herby > > > I would like to have more details about this. For those of us who don't believe in hell, what is the problem of an explicit Code of Conduct? Cheers, Offray |
|
|
> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: > > On 11/09/19 9:14 a. m., Herby Vojčík wrote: >> I found Contributor Covenant-derived Code of Conduct was added to >> Pharo, three months ago. This is unacceptable under any circumstances. >> >> Have fun in your woke hell. > > I would like to have more details about this. For those of us who don't > believe in hell, what is the problem of an explicit Code of Conduct? More specifically, what behavior does the Code prohibit that you would otherwise do? For my part, while I might not subscribe to the full progressive agenda, I wasn’t planning any racial or ethnic slurs (or a theological discussion of the afterlife—but feel free to ask me privately!), so don’t find this “woke” agenda too constricting. James |
|
|
> On 11 Sep 2019, at 19:07, James Foster <[hidden email]> wrote: > > >> On Sep 11, 2019, at 8:17 AM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote: >> >> On 11/09/19 9:14 a. m., Herby Vojčík wrote: >>> I found Contributor Covenant-derived Code of Conduct was added to >>> Pharo, three months ago. This is unacceptable under any circumstances. >>> >>> Have fun in your woke hell. >> >> I would like to have more details about this. For those of us who don't >> believe in hell, what is the problem of an explicit Code of Conduct? > > More specifically, what behavior does the Code prohibit that you would otherwise do? > > For my part, while I might not subscribe to the full progressive agenda, I wasn’t planning any racial or ethnic slurs (or a theological discussion of the afterlife—but feel free to ask me privately!), so don’t find this “woke” agenda too constricting. > > James Indeed. For those new to the discussion, we are talking about https://www.contributor-covenant.org/version/1/4/code-of-conduct - which is quite popular and generally accepted. Sven |
|
Administrator
|
Sven Van Caekenberghe-2 wrote
> https://www.contributor-covenant.org/version/1/4/code-of-conduct - which > is quite popular and generally accepted. Based on the reaction earlier in the thread, I was expecting something highly opinionated and polarizing, but it seems to boil down to: be professional and don't make it personal. While there are some categories of people mentioned, it doesn't seem to make a value judgement about them, but merely say that no one (including from those categories) will be harassed inside the Pharo community. Seems pretty reasonable, unless I'm missing something... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
|
|
In reply to this post by Sven Van Caekenberghe-2
I see no problem with having *a* code of conduct, but there are some worrying aspects of *this* code. Clearly there is a need for generality in any code, but the vagueness of the drafting seems to me to open it up to all sorts of mischief. Consider the paragraph:
" Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful."
The bits I have bolded mean that the maintainers can apply punitive measures based on what they deem inappropriate. Shouldn't the concept of "due process" come into this? The FAQ section, under the heading "What should I do if I have been accused of violating the code of conduct?", makes no mention of defending ones actions; the only option is to admit guilt and work with the accusers to reform.
The inclusion of the words "they deem" opens the way to all sort of subjectivity. Just for one instance, Sven recently thought it inappropriate that John Pfersich mentioned in passing in this list that, besides programming, his hobbies include shooting, which is a legal activity in most countries and an Olympic sport. Others disagreed in the thread, but Sven's message remained "don't do it." If John mentioned it again, could that be a violation of the code?
The fact that this particular code, evidently the creation of one person, is accepted by others should not mean it is automatically accepted. There is an obligation to look at it in detail; when I do, I think there are problems.
Peter Kenny
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. |
Administrator
|
Thanks for sharing that, Peter. It's an important point. On Wed, Sep 11, 2019 at 2:02 PM Peter Kenny <[hidden email]> wrote: I see no problem with having *a* code of conduct, but there are some worrying aspects of *this* code. Clearly there is a need for generality in any code, but the vagueness of the drafting seems to me to open it up to all sorts of mischief. Consider the paragraph: " Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful." The bits I have bolded mean that the maintainers can apply punitive measures based on what they deem inappropriate. Shouldn't the concept of "due process" come into this? The FAQ section, under the heading "What should I do if I have been accused of violating the code of conduct?", makes no mention of defending ones actions; the only option is to admit guilt and work with the accusers to reform. The inclusion of the words "they deem" opens the way to all sort of subjectivity. Just for one instance, Sven recently thought it inappropriate that John Pfersich mentioned in passing in this list that, besides programming, his hobbies include shooting, which is a legal activity in most countries and an Olympic sport. Others disagreed in the thread, but Sven's message remained "don't do it." If John mentioned it again, could that be a violation of the code? The fact that this particular code, evidently the creation of one person, is accepted by others should not mean it is automatically accepted. There is an obligation to look at it in detail; when I do, I think there are problems. Peter Kenny |
|
|
In reply to this post by Peter Kenny
First, apologies for the shambles of formatting this post. Secondly, having re-read it, I think it was inappropriate to mention Sven in the way I did. I still maintain that there are problems with the code, but I wish to retract the comments about Sven, and I apologise for including them. Peter Kenny From: Pharo-users <[hidden email]> On Behalf Of Peter Kenny I see no problem with having *a* code of conduct, but there are some worrying aspects of *this* code. Clearly there is a need for generality in any code, but the vagueness of the drafting seems to me to open it up to all sorts of mischief. Consider the paragraph: " Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful." The bits I have bolded mean that the maintainers can apply punitive measures based on what they deem inappropriate. Shouldn't the concept of "due process" come into this? The FAQ section, under the heading "What should I do if I have been accused of violating the code of conduct?", makes no mention of defending ones actions; the only option is to admit guilt and work with the accusers to reform. The inclusion of the words "they deem" opens the way to all sort of subjectivity. Just for one instance, Sven recently thought it inappropriate that John Pfersich mentioned in passing in this list that, besides programming, his hobbies include shooting, which is a legal activity in most countries and an Olympic sport. Others disagreed in the thread, but Sven's message remained "don't do it." If John mentioned it again, could that be a violation of the code? The fact that this particular code, evidently the creation of one person, is accepted by others should not mean it is automatically accepted. There is an obligation to look at it in detail; when I do, I think there are problems. Peter Kenny
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. |
|
|
In reply to this post by Herby Vojčík
> Why you changed `printSymbol: aClass name` > for `nextPutAll: aClass name`? Because there is no #printSymbol: anywhere in Pharo 7 or Pharo 8> , so I had to *guess* what it does, and the only reason I could see for using #printSymbol: instead of #print: is that class names are symbols and #print: will write a hash in front, and it seemed plausible that you would not want that hash. Accordingly I chose a well known, even standard, method that writes a class name with no extra decoration. > Now it outputs things incorrectly. You > should have changed it for `print: aClass name asSymbol` How is one supposed to *tell* what "correct" output is? If I wanted to write that code, I would be kind to my readers and make it *obvious* by doing stream nextPut; $#; nextPutAll: aClass name. I certainly would not go out of my way to confuse people by sending #asSymbol to something they already know is a Symbol. For what it's worth, I've attached my implementation. On Wed, 11 Sep 2019 at 21:46, Herby Vojčík <[hidden email]> wrote: On 11. 9. 2019 3:23, Richard O'Keefe wrote: |
puton.st (5K) |
|
In reply to this post by Sean P. DeNigris
There are some aspects of the "Covenant" that rub me up the wrong way. I note that the only part of it where anyone actually promises to do (or not do) anything is the "Pledge", which rather pointedly refrains from treating people with different political viewpoints (like gun ownership, or like TERFs who are silent about their opinions within the group) well. It's about supporting diversity of *being*, not diversity of *opinion*. There are other codes of conduct around which are framed in less identitarian terms. And it is rather startling to find that one is expected to be bound by a "Covenant" which is no Covenant (that is, an *agreement*). A code of conduct can be imposed from the top down; a covenant requires the consent of the governed. I am somewhat perturbed by the term "inclusive language" because it is a shifting standard. I have frequently heard young women addressing each other as "guys", yet have just recently watching someone basically saying "I know it's gender neutral now and there is no malice in it but it's exclusionary so it's really bad." So if you say something like "hey guys" in a message, you have just violated this covenant, and deserve to be thrown out. Or then again, you may not have. Who decides? In a world where an anti-racist black hero gets labelled a white supremacist, who decides? Here's another case. Many mailing lists or newsgroups have a policy "no homework answers". If you tell someone off for violating that policy, your mailing list or newsgroup is not welcoming and inclusive. In another mailing list I am on, there is a clear and explicit "no HTML postings" policy, for good topic-specific reason, and people are often (politely) told off for violating it. As I read the Covenant, that's not allowed. In a mailing list where you have no idea of my age, sex, body size, gender orientation, etc, much of the Covenant is prima facie pointless. The Covenant goes way too far to be a mere "be nice to each other" guide. I have no intention of giving offence, and I am I not going to pull out of the mailing list, but couldn't some less creepy code be adopted? On Thu, 12 Sep 2019 at 08:08, Sean P. DeNigris <[hidden email]> wrote: Sven Van Caekenberghe-2 wrote |
|
|
+100
/————————————————————/ For encrypted mail use [hidden email] Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org
|
|
|
In reply to this post by Sean P. DeNigris
On 2019-09-11 1:07 p.m., Sean P. DeNigris wrote:
> Based on the reaction earlier in the thread, I was expecting something > highly opinionated and polarizing, but it seems to boil down to: be > professional and don't make it personal. While there are some categories of > people mentioned, it doesn't seem to make a value judgement about them, but > merely say that no one (including from those categories) will be harassed > inside the Pharo community. Seems pretty reasonable, unless I'm missing > something... You're missing what some progressives consider harassment these days. These codes of conduct are being used around the net to force progressive political ideology into technical communities, the vague language is used to claim offense at any number of things like misgendering, or refusing to use any number of made up pronouns. Using inclusive language means using progressive language like ze/zir, per/pers, ey/em, xe/xem if someone demands it. This is language policing and a forcing of political ideology into what should not be political. People are being kicked out of communities for violating codes of conduct of the community outside of the community, i.e. you said something on twitter or facebook and now you're banned from an open source project for it even though it had nothing to do with the project. The person who created this particular code of conduct is a well known trans activist who first gets communities to accept the code of conduct, and then stalks people around web to find anything anywhere that might violate the vague code of conduct and then tries to cancel them in every community they're a part of. If you're not wary of this code of conduct, you're not paying attention to how it's being used out there. Here's a few quotes from the author of this code of conduct. "The Ruby community has no moral compass. Just aphorisms and self-congtatulatory, masturbatory bullshit." << after trying and failing to kick the creator of Ruby out of the Ruby community. "If you're not fighting alongside us, or lending support, you're STANDING IN OUR WAY. And I vow that I will walk right the fuck over you.". "Fact: the solution to the problems in tech is not more tech. Especially not more tech written by privileged, heads-in-the-sand white dudes." "So many cis het white tech dudes with large platforms on here, that not only don't engage in dialog on issues of social justice but don't even elevate the voices of those of us who do, ignoring POLITICS is a PRIVILEGE and I FUCKING SEE YOU." Here's a little history of this code of conduct and some other popular communities. https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ It's sad to see that Pharo has jumped onto this PC bandwagon, it does not bode well for the community. -- Ramón León |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |