Eyesee-Core(AndrewHora.100) extends Dictionary to add class method
#keys:values:
Here is the outline... --- | dict | dict := Dictionary new. ... ^dict --- So if I have [ Dictionary subclass: LEKImportedEnterpriseArchitectPackage ] then [ x := LEKImportedEnterpriseArchitectPackage keys: { #a . #b } values: { 1 . 2 } ] ends up with 'x' containing a Dictionary rather than a LEKImportedEnterpriseArchitectPackage. Is that a defect or by design ? I know there is some philosophy about avoiding subclassing collection classes so that they are used more "HAS A" rather than "IS A", but I'm not completely clear on that. My purpose is fairly simple providing a temporary staging point for records that I read in from a DBF file which I want to extract into my application format, to which I adding some convenience methods just to simply the import code. For example, there is no more logic in LEKImportedEnterpriseArchitectPackage besides getter methods like... --- packageID ^ self at: ‘Package_ID’ ---_primaryKey ^ self packageID --- cheers -ben _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On Sun, Jun 16, 2013 at 12:07 PM, Ben Coman <[hidden email]> wrote:
I believe it is a defect. Just updated the instantiation from "dict := Dictionary new" to "dict := self new.".
Now you x is a LEKImportedEnterpriseArchitectPackage.
Andre Hora _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Andre Hora wrote:
On Sun, Jun 16, 2013 at 12:07 PM, Ben Coman [hidden email] wrote:** Eyesee-Core(AndrewHora.100) extends Dictionary to add class method #keys:values: Here is the outline... --- | dict | dict := Dictionary new. ... ^dict --- So if I have [ Dictionary subclass: LEKImportedEnterpriseArchitectPackage ] then [ x := LEKImportedEnterpriseArchitectPackage keys: { #a . #b } values: { 1 . 2 } ] ends up with 'x' containing a Dictionary rather than a LEKImportedEnterpriseArchitectPackage. Is that a defect or by design ?I believe it is a defect. Just updated the instantiation from "dict := Dictionary new" to "dict := self new.". Now you x is a LEKImportedEnterpriseArchitectPackage. Thanks Andre. As an aside, regarding recent discussion about integrating Moose Collection-Extensions into Phaor, perhaps Dictionary class>>keys:values: could be considered for inclusion. I found it quite useful, per my use case below... ------------- loadAll: recordTypeClass fromXbaseFile: filename " LEKEnterpriseArchitectXbaseImporter new loadFromXbaseFile: 't_package.dbf'. " | xbaseFile importedRecords fieldNames | importedRecords := Dictionary new. [ xbaseFile := XBaseFile on: self folder , filename. fieldNames := xbaseFile fields. Cursor read showWhile: [ xbaseFile contents do: [ :xbaseRecord | | importedRecord | importedRecord := recordTypeClass keys: fieldNames values: xbaseRecord . "<------Use Case" importedRecords at: importedRecord _primaryKey put: importedRecord . ] ] ] ensure: [ xbaseFile ifNotNil: [ xbaseFile close ] ]. ^importedRecords ------------- cheers -ben I know there is some philosophy about avoiding subclassing collection classes so that they are used more "HAS A" rather than "IS A", but I'm not completely clear on that. My purpose is fairly simple providing a temporary staging point for records that I read in from a DBF file which I want to extract into my application format, to which I adding some convenience methods just to simply the import code. For example, there is no more logic in LEKImportedEnterpriseArchitectPackage besides getter methods like... --- packageID ^ self at: ‘Package_ID’ --- _primaryKey ^ self packageID --- cheers -ben _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |