Closed carasuca closed 12 years ago
Sorry, one place missed. Corrected.
@themoob why different enums for xml and generic param? can't xml params be extended so generic param can reuse xml?
@carasuca You'd need to be more elaborate about this. Maybe we should talk it over in person some day.
Generally, we were trying to be backward-compatible with already written plugins and this is why we left those xml param constants there. I personally hate them, so I made my simple, lowercase param types and use it for json all around, but needed to make a two-way converter on exe boundaries.
Hope we're gonna switch to my string constants rather than these monster bloated freakin-ellipsis-ended goddamn-xml param definitions. Yeah, I dislike them. Actually, when we're on it, we should switch to json. The developer is already abstracted from composing xml :)
Oh, you meant enums, not strings...
json is the way to go. the question is when?
I'd leave it till at least 2.0. Time to cool stuff down and still serious features to implement...
why different enums for xml and generic param? can't xml params be extended so generic param can reuse xml?
Because XMLIOUtilities is queued for removal. As you said, XML will be changed to JSON or some other thing one day, so it would be pointless to keep this mmXML::mmXMLDataType enum.
OK, this is good. The user doesn't have to be aware of XML tags.
yet another enum mapping problem:
plugin\mmcalcmethod.h(146): error C2664: 'mmImages::BindParam' : cannot convert parameter 3 from 'const mmXML::mmXMLDataType' to 'const mmImages::mmGenericParamI::mmType'
-1 for in-header implementation -1 for functor object :)