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

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by Dale Henrichs

Euan, What I meant is that you can't _always_ use the code point for collation, i.e., sorting based on the value of code points is not always correct[1]. If I'm not mistaken the fully-composed and fully-decomposed forms can only be used for testing the equivalence of two strings[2] ... The Main Algorithm[3], starts by producing a normalized form of the string, but the subsequent steps (produce array, form sort key and compare) involves table lookups among other things .... Once you've produced a sort key for a string, the sort key does use "binary comparison" for collating , which is a byte by byte numeric comparison ... Dale [1] http://www.unicode.org/reports/tr10/#Common_Misperceptions [2] http://unicode.org/reports/tr15/pdtr15.html [3] http://www.unicode.org/reports/tr10/#Main_Algorithm On 12/08/2015 12:22 PM, EuanM wrote: > Dale - is that you can't depend on the value of a codepoint > *unless the string is either in fully-composed form > (or has just been fully-decomposed from a fully-composed form) * > > OR are there circumstances where even those two cases cannot be relied upon? > > On 8 December 2015 at 19:20, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> >> On 12/07/2015 11:31 PM, H. Hirzel wrote: >>> Dale >>> >>> Thank you for your answer with links to the ICU library and the notes >>> about classes in Gemstone. Noteworthy that you have a class Utf8 as a >>> subclass of ByteArray. >>> >>> I understand that Gemstone uses the ICU library and thus does not >>> implement the algorithms in Smalltalk. >>> >>> I am currently looking into what the ICU library provides. >>> >>> I found as well a Ruby library [2] which implements CLDR [3] >>> >>> It has methods like this >>> >>> "Alphabetize a list using regular Ruby sort:" >>> >>> $> ["Art", "Wasa", "Ãlg", "Ved"].sort >>> $> ["Art", "Ved", "Wasa", "Ãlg"] >>> >>> Alphabetize a list using TwitterCLDRâs locale-aware sort: >>> >>> $> ["Art", "Wasa", "Ãlg", "Ved"].localize(:de).sort.to_a >>> $> ["Ãlg", "Art", "Ved", "Wasa"] >>> >>> I hope that given such an example it would not be too difficult to >>> reimplement a similar sort algorithm in Squeak/Cuis/Pharo. Currently >>> the interest is in getting sorting done in a cross-dialect-way. >>> >> I think that the issue (from a performance perspective) is that you can't >> depend upon the value of the code point when doing collation --- the main >> algorithm[5] is pretty much table based --- In addition to the different >> sort orders based on characters there are even more arcane sort rules where >> characters at the end of a word can affect the sort order of the word (for >> more info see[4]). >> >> It is worth looking at the Conformance section of the Unicode spec[1] as >> there are different levels of collation conformance ..... >> >> ICU conforms[2] to to UTS #10[3], the highest level of conformance ... >> >> It looks like TwitterCLDR[6] uses the Main Algorithm[5] with tailoring[7]. >> They don't claim to be conformant to the Unicode Collation Algorithm[3], but >> they are covering a big chunk of the standard use cases .... >> >> Dale >> >> [1] http://unicode.org/reports/tr10/#Conformance >> [2] http://userguide.icu-project.org/collation >> [3] http://www.unicode.org/reports/tr10/ >> [4] http://www.unicode.org/reports/tr10/#Introduction >> [5] http://www.unicode.org/reports/tr10/#Main_Algorithm >> [6] >> https://blog.twitter.com/2012/twittercldr-improving-internationalization-su… >> [7] http://unicode.org/reports/tr10/#Tailoring

Dec. 8, 2015

Re: [Pharo-dev] Unicode Support

by EuanM

"No. a codepoint is the numerical value assigned to a character. An "encoded character" is the way a codepoint is represented in bytes using a given encoding." No. A codepoint may represent a component part of an abstract character, or may represent an abstract character, or it may do both (but not always at the same time). Codepoints represent a single encoding of a single concept. Sometimes that concept represents a whole abstract character. Sometimes it represent part of an abstract character. This is the key difference between Unicode and most character encodings. A codepoint does not always represent a whole character. On 7 December 2015 at 13:06, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 07 Dec 2015, at 1:05 , EuanM <euanmee(a)gmail.com> wrote: > > Hi Henry, > > To be honest, at some point I'm going to long for the for the much > more succinct semantics of healthcare systems and sports scoring and > administration systems again. :-) > > codepoints are any of *either* > - the representation of a component of an abstract character, *or* > eg. "A" #(0041) as a component of > - the sole representation of the whole of an abstract character *or* of > - a representation of an abstract character provided for backwards > compatibility which is more properly represented by a series of > codepoints representing a composed character > > e.g. > > The "A" #(0041) as a codepoint can be: > the sole representation of the whole of an abstract character "A" #(0041) > > The representation of a component of the composed (i.e. preferred) > version of the abstract character â« #(0041 030a) > > â« (#00C5) represents one valid compatibility form of the abstract > character â« which is most properly represented by #(0041 030a). > > â« (#212b) also represents one valid compatibility form of the abstract > character â« which is most properly represented by #(0041 030a). > > With any luck, this satisfies both our semantic understandings of the > concept of "codepoint" > > Would you agree with that? > > In Unicode, codepoints are *NOT* an abstract numerical representation > of a text character. > > At least not as we generally understand the term "text character" from > our experience of non-Unicode character mappings. > > > I agree, they are numerical representations of what Unicode refers to as > characters. > > > codepoints represent "*encoded characters*" > > > No. a codepoint is the numerical value assigned to a character. An "encoded > character" is the way a codepoint is represented in bytes using a given > encoding. > > and "a *text element* ... > is represented by a sequence of one or more codepoints". (And the > term "text element" is deliberately left undefined in the Unicode > standard) > > Individual codepoints are very often *not* the encoded form of an > abstract character that we are interested in. Unless we are > communicating to or from another system (Which in some cases is the > Smalltalk ByteString class) > > > > > i.e. in other words > > *Some* individual codepoints *may* be a representation of a specific > *abstract character*, but only in special cases. > > The general case in Unicode is that Unicode defines (a) > representation(s) of a Unicode *abstract character*. > > The Unicode standard representation of an abstract character is a > composed sequence of codepoints, where in some cases that sequence is > as short as 1 codepoint. > > In other cases, Unicode has a compatibility alias of a single > codepoint which is *also* a representation of an abstract character > > There are some cases where an abstract character can be represented by > more than one single-codepoint compatibility codepoint. > > Cheers, > Euan > > > I agree you have a good grasp of the distinction between an abstract > character (characters and character sequences which should be treated > equivalent wrt, equality / sorting / display, etc.) and a character (which > each have a code point assigned). > That is besides the point both Sven and I tried to get through, which is the > difference between a code point and the encoded form(s) of said code point. > When you write: > "and therefore encodable in UTF-8 as compatibility codepoint e9 hex > and as the composed character #(0065 00b4) (all in hex) and as the > same composed character as both > #(feff 0065 00b4) and #(ffef 0065 00b4) when endianness markers are > included" > > I's quite clear you confuse the two. 0xFEFF is the codepoint of the > character used as bom. > When you state that it can be written ffef (I assume you meant FFFE), you > are again confusing the code point and its encoded value (an encoded value > which only occurs in UTF16/32, no less). > > When this distinction is clear, it might be easier to see that value in that > Strings are kept as Unicode code points arrays, and converted to encoded > forms when entering/exiting the system. > > Cheers, > Henry >

Dec. 8, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by EuanM

"What you lose is the right to take out your code (and to change the licensing of it retroactivelyâ¦)." That is only true in one sense. 1) The author cannot demand that the code is removed from the codebase - as the original grant of licence was irrevocable. (Or at least, this is proven true in UK and US jurisdictions - I have no knowledge of the case mutability of French law). The author *can* request that, and the publishers can accede to that request, if they choose. 2) The author cannot demand to have the terms of licence changed for code which has been accepted into the codebase. The author *can* request that, and the publishers can accede to that request, if they choose. 3) The author wrote the code, and provided a copy of it to the publisher. Unless s/he explicitly provided sole use to the publisher, he can provide that same code to any other group or publisher as s/he sees fit, under any license terms (or none) s/he chooses. Providing a copy of the code under a different licence is functionally equivalent to some interpretations of the quoted sentence. On 8 December 2015 at 10:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > so, first of all, I find the way you communicate your arguments a bitâ¦ well, > not very polite. > second, even Benâs affaire should show you why we value this license > agreements. > third, French laws are French laws and since the development of Pharo is in > a big extent made here (through INRIA), French laws needs to be fulfilled. > And no, there are no exceptionsâ¦ we wouldnât be able to operate here without > that: French law does not recognise digital signatures, checkbox or anything > that comes from the âvirtual worldâ (we have a lot of funny examples of > things we decide to to request from other EU countries because if we request > it here, we need to send them a contract by mail). > four, no copyright is lost. Your code keeps your name, etc. What you lose is > the right to take out your code (and to change the licensing of it > retroactivelyâ¦). > five, nobody forces you to do anything. Iâm really sorry you take this as a > personal prosecution (or a personal battle)â¦ while I value all contributions > and discussions (and I certainly would like you continue contributing), I > find the tone of your reclamation a little bit out-of-the-tone of a real > argumentationâ¦ kind of trollishâ¦ so I wonder if you really want to discuss > something or notâ¦ > > cheers! > Esteban > > On 08 Dec 2015, at 00:47, webwarrior <reg(a)webwarrior.ws> wrote: > > Considering that there are a couple of responses and the fact that you > guys are so easily offended, I will not answer everyone but just state > couple of theses. > > > 0. I will not reveal my real name, because I value privacy. Nickname is > sufficient for identification purposes. Any other information (real > name, address, etc.) is not needed for actually contributing code. Think > of principle of least privilege. > > 1. I could easily make up some human-looking name (Satoshi Nakamoto > anyone?), but will not do it out of principle (see #0). > > 2. Knowing contributor's "real" name would not guard you against any > possible malicious actions from him, because it can't be verified (see > #1). One can also make up address, and even signature, if needed, and I > bet no one would spot it. > > 3. I don't buy argument about requirements of some organizations. Linux > kernel is used in billions of devices and by countless organizations, > and I highly doubt that contributing to Linux requires anything like > singing an agreement or whatever. > > 4. Even in paid services checking a checkbox is usually sufficient for > accepting any license/ToS. > > 5. My intentions are mostly of pragmatic nature. To make things that I > use (and that can be useful to Pharo users) be in upstream. > > 6. I don't care whether you drink beer, your political views, or your > interpersonal relationships (however story with Benjamin shows that > perhaps everything's not as great as you paint it). These are all > irrelevant to Pharo development, from my point of view at least. > > 7. If you don't agree with my arguments and stick to your rules, go for > it. I'm in no position to tell you what's the right thing to do. I'll > just end this discussion and leave. > > ________________________________ > View this message in context: Re: License agreement - are you kidding me? > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Dec. 8, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by EuanM

"The Pharo community is quite small" Yes, and that is a major issue. Both for feature-completeness in a timely fashion, and also for commercial uptake of use of Pharo. Saying that it's small, so it's okay to make it difficult for people to join is... self-fulfilling. On 8 December 2015 at 07:35, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On 12/07, webwarrior wrote: >> It would be logical to make contribution to an open source project easy, >> right? >> Well, in bigger projects some burocracy is inevitable, but usually has some >> valid reasons behind it. >> >> When I made some commits to Spec (while it was on github), it was as easy as >> fork->commit->create pull request. >> In Pharo, it's already more complicated: you have to register yourself in >> SmalltalkHub, in fogbugz, in mailing lists. Slices system is also not very >> intuitive. Then CI system spits out some completely unrelated errors. >> >> But OK, I understand that Pharo is unlike > > Not every project lives in GitHub. > For Ruby, Mozilla, Chromium, Python, PHP, ... you have to register to > their bug tracker. After all, these projects predate both GitHub AND > git. > >> Then people began asking me of my real name - which is already wierd - why >> would they need it? > > The Pharo community is quite small and many people know each other > personally (have met on Pharo Days, ESUG, are coworkers, ...). So > working with someone who goes well out of his way to remain anonymous may be > uncomfortable for some. Not to mention that such behavior may seem > strange for OSS, but that's your call. > >> >> And then someone suggested that I must sign license agreement (which is also >> wierd - MIT license doesn't demand anything like that). > > The MIT may not demand something like that, however signing License > Agreement is also not completely unheard of, see for example > https://en.wikipedia.org/wiki/Contributor_License_Agreement#Users > > This includes names like Python, Apache, jQuery, Django, ... not exactly > small fishes. > > >> I looked at that agreeement. It requires you to provide name, address (???), >> sgin it and send it via snail mail (WTF???). > > See above. Also note that copyright in many countries recognized > pseudonyms as valid authors. (I am not familiar with French law, but I will assume it is harmonized across EU) > Of course in case of a dispute you would need to be able to prove that > you are the pseudonym (otherwise you yourself would loose the rights). > > So considering your position (revealing your real name would undermine > all the work you've put into protecting it), going with a pseudonym if > you are indeed willing to contribute may be the best course of action. > >> -- >> View this message in context: http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > > -- > Peter >

Dec. 8, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by EuanM

"partially anonymous" The correct word is "pseudonimity". In UK law, as long as there is no intent to defraud, you can call yourself anything you like. In UK, you can provide signatures digitally, completely legally. UK law is has a long tradition of sorting out legal issues between two-third party jurisdictions. Perhaops Pharo ought to do it's work under a legal system that is more completely designed to handle issues of international commerce? Or perhaps it should be a all-French affair. On 7 December 2015 at 20:26, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi webwarrior (or whatever your name now is ;) > > There is always room for improvements - even for better guidance on how to become > a contributor. There are good reasons to do things the way they are done now - and > yes some of them are not optimal because of history or because of sparse time. > > Lamenting partially anonymous from the outside is neither useful nor polite. > Working as a real member/part of the community on the other side can help us all to move > forward step by step with a better open source project. > > If you or any other is really interested in moving with us the registration or > signature for sure will not be the show stopper. > >>Either we skip this stupid formality and continue working on the code, or >>I'm out of this. > > As Stef explained this was not done to bug people or keep them away. > We know that it might be cumbersome at first sight - but hey, many people mastered this > easily. I guess we even have people who do not drink beer but wine instead :) > > You can decide on your own how to proceed. Turn away or return. I guess there is only > one big hurdle and this one is on your side ;) > > As you see friendly people continue to invest their time answering your mails although you > as the author not even have the time (or will) to reveal your name. IMHO if someone > wants to participate in an open source project he has to be "open" on its own side first. > > It's up to you... > > Thanks > T. > > >

Dec. 8, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by EuanM

Dale - is that you can't depend on the value of a codepoint *unless the string is either in fully-composed form (or has just been fully-decomposed from a fully-composed form) * OR are there circumstances where even those two cases cannot be relied upon? On 8 December 2015 at 19:20, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 12/07/2015 11:31 PM, H. Hirzel wrote: >> >> Dale >> >> Thank you for your answer with links to the ICU library and the notes >> about classes in Gemstone. Noteworthy that you have a class Utf8 as a >> subclass of ByteArray. >> >> I understand that Gemstone uses the ICU library and thus does not >> implement the algorithms in Smalltalk. >> >> I am currently looking into what the ICU library provides. >> >> I found as well a Ruby library [2] which implements CLDR [3] >> >> It has methods like this >> >> "Alphabetize a list using regular Ruby sort:" >> >> $> ["Art", "Wasa", "Ãlg", "Ved"].sort >> $> ["Art", "Ved", "Wasa", "Ãlg"] >> >> Alphabetize a list using TwitterCLDRâs locale-aware sort: >> >> $> ["Art", "Wasa", "Ãlg", "Ved"].localize(:de).sort.to_a >> $> ["Ãlg", "Art", "Ved", "Wasa"] >> >> I hope that given such an example it would not be too difficult to >> reimplement a similar sort algorithm in Squeak/Cuis/Pharo. Currently >> the interest is in getting sorting done in a cross-dialect-way. >> > > I think that the issue (from a performance perspective) is that you can't > depend upon the value of the code point when doing collation --- the main > algorithm[5] is pretty much table based --- In addition to the different > sort orders based on characters there are even more arcane sort rules where > characters at the end of a word can affect the sort order of the word (for > more info see[4]). > > It is worth looking at the Conformance section of the Unicode spec[1] as > there are different levels of collation conformance ..... > > ICU conforms[2] to to UTS #10[3], the highest level of conformance ... > > It looks like TwitterCLDR[6] uses the Main Algorithm[5] with tailoring[7]. > They don't claim to be conformant to the Unicode Collation Algorithm[3], but > they are covering a big chunk of the standard use cases .... > > Dale > > [1] http://unicode.org/reports/tr10/#Conformance > [2] http://userguide.icu-project.org/collation > [3] http://www.unicode.org/reports/tr10/ > [4] http://www.unicode.org/reports/tr10/#Introduction > [5] http://www.unicode.org/reports/tr10/#Main_Algorithm > [6] > https://blog.twitter.com/2012/twittercldr-improving-internationalization-su… > [7] http://unicode.org/reports/tr10/#Tailoring

Dec. 8, 2015

Re: [Pharo-dev] Documentation epiphany

by EuanM

The joke it's based on pre-dates use of computers to render complex 3D :-) Here's the world's first computer-generated 3D movie, from the Uni of Utah in 1972: https://vimeo.com/16292363 Compiled languages predate this. On 8 December 2015 at 15:24, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Actually this joke I think is "stolen" by a previous joke about 3d artists , > because our rendering times can be way longer than compiling the most > complex C++ code. Easily can reach months of rendering time. > > Its a good joke, but it should be taken as it is , a joke and nothing more. > > Because I happen to build blender from time to time which is 1 million lines > of destruction code, aka C/C++ code. Compiling is not that bad. Sure C++ > still is hog slow and outperformed 10 times by Pascal compilers which I > think that even the Pharo compiler would have a hard time competing with. > But makefiles are smart enough to compile and re link whatever it changes > and not the whole project. > > So each new commit I fetch for Blender produces a couple of seconds of > compiling time. But the very first compile which compiles everything from > scratch can reach even an hour and is not even a complete compile since I > use many prebuilt libraries and some prebuilt dependencies. > > To the subject of documentation it comes attached with a big depends. > Documentation is the usual problem pretty much with any programming > languages and is based on the fact that coders dont like to document as much > they dont like to design good code and make very good GUIs. > > Frankly you should always feel glad if you find documentation in any > language your are coding. If its good documentation too, then its your lucky > day indeed. > > But even in popular languages like Python, sure plenty of documentation for > the standard stuff but the moment you start depend on third party libraries > you are all alone VS the Alien :D > > On Tue, Dec 8, 2015 at 4:42 PM Ben Coman <btc(a)openinworld.com> wrote: >> >> I just understood! Other languages might get better documentation >> because of all the extra slack time they get between compile cycles, >> that we don't get with Pharo's tight code-run-debug loop. >> >> I know... not a valid excuse for us**, but then I get to show this... >> https://xkcd.com/303/ >> >> ** of course documentation is getting better every day - but I can't >> let the truth get in the way of a good story :) >> >> cheers -ben >> >

Dec. 8, 2015

Re: [Pharo-dev] [Unicode] Normalization -- canonical equivalence vs compatibility equivalence

by EuanM

canonical equivalence ================ aString = anotherStrong where both strings are of the same sequence of valid Unicode representations of abstract characters BUT each individual character MAY (or may not) be represented by different valid Unicode representations of the character e.g. #(00c5) = #(212b) = #(0041 030a) "The same meaning when printed or displayed" Every tuple of canonically equivalent sequences is also compatibility equivalent. Actually yes - the easy way to define it would be a canonically equivalent string is the same string sequence of the same abstract characters as the string you are comparing it to. (But may use different codepoints) The sequence will have the same glyph appearance. compatibility equivalence is ===================== aString = anotherStrong where both strings have the same meaning in some particular contexts, but may have a different glyph appearance e.g. comparing ligatures with the decomposed sequences making up a ligature as in "ss" = "Ã" This is compatibility equivalent, they *can* have the same meaning, but they never have the same appearance. The normalisation forms either - expand all compatibility codepoints into fully composed sequences, to create the "fully composed normal form" of the string OR fully condense all composed sequences into compatibility codepoints, to create a "fully decomposed normal form". (Note, that as there can be multiple compatibility codepoints for an abstract character, it is necessary to create fully decomposed forms only after first coverting to fully composed forms, or two fully decomposed strings could fail equivalance testing *despite* being compatibility equivalent. e.g. #(00c5 00c5 00c5) = #(212b 212b 212b) is actually true, for compatibility equivalence But a process of fully composing any of #(00c5 212b #(0041 030a) ) #(00c5 00c5 00c5) #(212b 212b 212b) would always produce #( #(0041 030a) #(0041 030a) #(0041 030a) ) and then a subsequent full decomposition would produce #(00c5 00c5 00c5) for all three cases. On 8 December 2015 at 16:09, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > It seems that going for Normalization first in order to implement > String comparison is the next necessary steps. This is already a > result by itself. > > Normalization (Unicode) > Last updated at 4:05 pm UTC on 8 December 2015 > http://wiki.squeak.org/squeak/6229 > > Can you explain to me what the difference between > > canonical equivalence > and > compatibility equivalence > > and for which we should go? > > --Hannes

Dec. 8, 2015

Re: [Pharo-dev] [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: [squeak-dev] Unicode Support))

by Dale Henrichs

On 12/07/2015 11:31 PM, H. Hirzel wrote: > Dale > > Thank you for your answer with links to the ICU library and the notes > about classes in Gemstone. Noteworthy that you have a class Utf8 as a > subclass of ByteArray. > > I understand that Gemstone uses the ICU library and thus does not > implement the algorithms in Smalltalk. > > I am currently looking into what the ICU library provides. > > I found as well a Ruby library [2] which implements CLDR [3] > > It has methods like this > > "Alphabetize a list using regular Ruby sort:" > > $> ["Art", "Wasa", "Ãlg", "Ved"].sort > $> ["Art", "Ved", "Wasa", "Ãlg"] > > Alphabetize a list using TwitterCLDRâs locale-aware sort: > > $> ["Art", "Wasa", "Ãlg", "Ved"].localize(:de).sort.to_a > $> ["Ãlg", "Art", "Ved", "Wasa"] > > I hope that given such an example it would not be too difficult to > reimplement a similar sort algorithm in Squeak/Cuis/Pharo. Currently > the interest is in getting sorting done in a cross-dialect-way. > I think that the issue (from a performance perspective) is that you can't depend upon the value of the code point when doing collation --- the main algorithm[5] is pretty much table based --- In addition to the different sort orders based on characters there are even more arcane sort rules where characters at the end of a word can affect the sort order of the word (for more info see[4]). It is worth looking at the Conformance section of the Unicode spec[1] as there are different levels of collation conformance ..... ICU conforms[2] to to UTS #10[3], the highest level of conformance ... It looks like TwitterCLDR[6] uses the Main Algorithm[5] with tailoring[7]. They don't claim to be conformant to the Unicode Collation Algorithm[3], but they are covering a big chunk of the standard use cases .... Dale [1] http://unicode.org/reports/tr10/#Conformance [2] http://userguide.icu-project.org/collation [3] http://www.unicode.org/reports/tr10/ [4] http://www.unicode.org/reports/tr10/#Introduction [5] http://www.unicode.org/reports/tr10/#Main_Algorithm [6] https://blog.twitter.com/2012/twittercldr-improving-internationalization-su… [7] http://unicode.org/reports/tr10/#Tailoring

Dec. 8, 2015

Unified Property API and persistent properties (Pharo 5)

by Torsten Bergmann

In Pharo 5 the "properties" API is unified (means you can associate properties to classes, methods, packages, ...). Really cool and a good step toward a unified and more flexible system. Exampel: |pck| pck := #'Foo-Kernel' asPackage. pck propertyAt: #'lastModified' put: DateAndTime now asString. pck propertyAt: #'generatedUsing' put: 'Pharo DynaCase'. pck properties So far it looks like the package properties are still transient - that means when you save the package and load in another image they will be empty again. Havent tried for class properties, ... Will this change in the near future so they are persistent? I wonder what the plans an next steps are in this area. Thanks T.

Dec. 8, 2015