Dictionary class>>keys:values:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Dictionary class>>keys:values:

Ben Coman
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
Reply | Threaded
Open this post in threaded view
|

Re: Dictionary class>>keys:values:

Andre Hora
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.

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




--
Andre Hora

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dictionary class>>keys:values:

Ben Coman
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


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev