Re: [Dxfreader-info] BLOCKS refactor and BBDXFTuple rename

[Allan D. <al...@br...>]

TaskFreak and Mantis are turned on. I don't know if I need to create  
accounts/users for you or if you do that yourself. Give it a shot and  
let me know what you find out.

-Allan


On Mar 25, 2009, at 7:11 AM, Allan Daly wrote:

> Mike,
>
> You're exactly right on not needing a custom collection --  
> NSMutableArray will work fine and that makes the most sense. I'm not  
> sure where my head was that day but I'd like to think I would have  
> come around to your suggestion eventually. That's the way I will go.
>
> Tuple -- didn't realize this was a mathematics term. I had not heard  
> that one before. I think DXFDataPair sounds fine.
>
> I will turn on (opt in to) TaskFreak and Mantis and let's see how  
> that goes. Good suggestions.
>
> Finally, a definite yes to your proposal to only commit code that  
> successfully passes the unit tests, and to create unit tests for new  
> features as they proceed. Prior to the commits in SF I had been  
> using my simple DrawKit implementation as an informal unit testing  
> setup. Making this more formal and structured is the right things to  
> do -- especially now that you've figured everything out and done the  
> hard part.
>
> Thanks.
>
> -Allan
>
>
> On Mar 23, 2009, at 11:28 AM, Michael Caron wrote:
>
>> Hey Allan,
>>
>> Regarding the collection object:
>> ----------------------------------------------
>> I agree that we should move the accessor methods out of the Model  
>> object and into container objects. However, I'm not convinced that  
>> a specific collection class has to be written. NSMutableArray is a  
>> sufficient object to use and has everything that we need to do,  
>> including enumerators. I can only see one benefit to a custom  
>> collection class and that's just to make sure that we're only  
>> adding DXFEntity objects to it. I think that using standard  
>> NSMutableArray and NSMutableDictionary objects are sufficient and  
>> then we don't have to maintain the collection code. Thus, we'd have  
>> something like this:
>>
>>     BBDXFModel      m = [[BBDXFModel  alloc] init];
>>   BBDXFParser     p = [[BBDXFParser alloc] initWithModel: m];
>>   [parser parse];
>>
>>   NSArray*        entities = [m  
>> entities];                                 // read only array  
>> interpretation
>>   float           x        = [[[entities objectAtIndex:0]  
>> startPoint] x];  // supposing that element 0 of the entities coll'n  
>> is a line
>>   NSMutableArray* entities = [m  
>> entities];                                 // add/remove to array  
>> implementation
>>   BBDXFEntity*    e        = [[[m blocks] objectAtIndex:0]  
>> entities];      // obtain the entity collection from the first  
>> block object
>>
>> Objective-C's dynamic typing is a real life-saver here. I think  
>> that the standard Cocoa collection objects really give us the  
>> obvious behavior that we need. So the parser would do the following  
>> to add a line entity to the model:
>>
>>    // have obtained a BBDXFEntityLine "l"
>>  [[model entities] addObject: l];
>>
>> It's straight forward and any ObjC programmer can look at that and  
>> know what's going on.
>>
>> If there is another benefit that you see to using a custom  
>> collection that I don't see, however, please discuss it. I'm not  
>> trying to crush an idea, just sharing my opinion and still open for  
>> discussion. Perhaps I'm not seeing how one might think of "blocks".  
>> I didn't get the dynamic typing stuff in the beginning so I might  
>> have some cast operators that I need to clean up, BTW.
>>
>> Regarding the Tuple:
>> -----------------------------
>> You're right. I re-read the defn' of "Tuple" and I had  
>> misunderstood. In Mathmatics, a Tuple is a set. I thought it had  
>> the added property that it was also a pair. How about we name it  
>> DXFDataPair? I find "Twople" a bit hard to read. I first read it as  
>> "twopple", sounding like "topple" but with a 'wuh' sound in there,  
>> i.e. "tuh-wop-pel". Here's where a recording would be nice, eh? :)
>>
>> Regarding workload:
>> -----------------------------
>> 1. We could start a TaskFreak list on our sourceforge project.  
>> SourceForge hosts a good amount of development related apps for  
>> project use and all they require is opt-in by the project admin  
>> (i.e. you). TaskFreak seems easy enough, just a web-based TODO  
>> system. We could add todo items to the list and then assign them to  
>> ourselves. That way we have a record of features we implemented.
>>
>> 2. We could start a Mantis BugTracking list (one of SF's hosted  
>> apps). And treat each feature as a separate item in the bug list.  
>> Assign yourself to one of the bugs/features and we know who's  
>> working on that.
>>
>> 3. Simple announcement to the list that you're working on X and  
>> then another note to say you're done with it. Discussion over  
>> piggybacking on to work can happen also.
>>
>> What do you think?
>>
>> General Practice:
>> --------------------------
>> I would also say that we don't commit code that breaks the unit  
>> tests. I would want to add that we don't add code without tests  
>> that cover it in a sufficient manner, not totally exhaustive, but  
>> most logical paths are covered. If you're not too comfy with unit  
>> tests yet, that's cool. But that'll be my M.O. so I can keep  
>> quality high.
>>
>> Ciao,
>> Mike
>>
>>
>> Allan Daly wrote:
>>>
>>> Mike,
>>>
>>> I started to tackle the BLOCKS logic/parsing/etc. A BLOCK definition
>>> in the BLOCKS section is a collection of regular DXF entities that  
>>> are
>>> defined exactly the same in the BLOCKS section as they are in the  
>>> main
>>> ENTITIES section. The one difference is that a BLOCK definition has
>>> some meta-data attached to it -- a name, some flags, an XYZ origin
>>> point for example. Entities inside the block have their XYZ
>>> coordinates set relative to this block origin point.
>>>
>>> Both a BLOCK definition and the ENTITIES section contain a  
>>> collection
>>> of entities. In order to structure things cleanly I think we need to
>>> refactor the entities array and accessor methods out of the  
>>> BBDXFModel
>>> object and create a new BBDXFEntitiesCollection object to hold them
>>> instead.
>>>
>>> A BBDXFModel can then contain one of these entity collections to
>>> represent the main entities collection and a BBDXFBLock can also
>>> contain one of these entity collections to contain all the entities
>>> associated with that block.
>>>
>>> The BBDXFModel can also of course contain all the other model data
>>> defined in the drawing (the header dictionary you created, for
>>> example) and the BBDXFBlock object can contain all the block meta- 
>>> data.
>>>
>>>
>>> The other thing I wanted to suggest is that your BBDXFTuple object  
>>> be
>>> renamed to DXFTwople. Since it's just an internal private object,
>>> there's no need to put the BB on there since it will not be  
>>> reference
>>> or reused publicly and there's no chance for any confusion with  
>>> anyone
>>> else's Tuple (or Twople) object. Second since the object refers to a
>>> pair of two lines inside the DXF file, I think using the word  
>>> "two" in
>>> there would make things a bit clearer. Once upon a time I did a  
>>> lot of
>>> theater and there was a "twofer" plug that allowed you to put two
>>> theatrical lights into one plug. The "two" helps explain things --
>>> your "tu" confused me on the first pass through. Are you OK with
>>> renaming that? I propose "DXFTwople."
>>>
>>>
>>> The next big topic here is who does what and how do we coordinate?
>>> Let's make a plan for working in parallel and then I'll dive in to
>>> these changes. I also want to hear your thoughts on these changes.
>>>
>>> Thanks.
>>>
>>> -Allan
>>>
>>> ------------------------------------------------------------------------------
>>> Apps built with the Adobe(R) Flex(R) framework and Flex  
>>> Builder(TM) are
>>> powering Web 2.0 with engaging, cross-platform capabilities.  
>>> Quickly and
>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
>>> development
>>> software that enables intelligent coding and step-through debugging.
>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>>> _______________________________________________
>>> Dxfreader-info mailing list
>>> Dxf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dxfreader-info
>>>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
> are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly  
> and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
> development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com_______________________________________________
> Dxfreader-info mailing list
> Dxf...@li...
> https://lists.sourceforge.net/lists/listinfo/dxfreader-info