On 6/24/08, Satish Balay <[email protected]> wrote:

Expecting users to use 'const char*' is "perfectly reasonable" - but expecting users to use 'const VecType' (which is a predefied type) is a step below it. [esp when we don't have const Mat, const Vec etc...].

So the above expectation assumes the user knows the internal impl of this type is 'char *' - etc.. - and its not 'const *' due to these implemenation issues etc..

So I think the current expectation is a minor deviation - and what I propose is also a minor hack.. [with a benifit of more consistant user code]. So whatever option we choose - we do it by accepting the limitation of that choice.

Satish, all my previous objections were all related to your previous comments.

I guess part of the design issue is: we have a requirement for 'VecType' functionality. Initially we choose 'enum' for this. This choice had limitations [could not add new types].

Well, the an approach like PetscCookie would permit to create new types, but IMHO, that would be overkill.

Then we choose "char *" which evolved into "const char*" due to compiler issues. But now we have new issues with the 'const' side of things - limiting the extensibility of 'VecType'. [cannot dynamically construct a string and assign is as a new type]

Well, that's not completelly true. What's wrong with building a type name from pieces in a temporary char[] (non-const) buffer, and pass it to XXXSetType() ?? Of course, PETSc internals will have to deal with the implementation detail of VecType, but the majority of USER code would be alleviated of such a detail.

Perhaps we should get away from strings [and its implemetation consequences] - and look for a better way to abstact out the impl details from the interface requirements. [I don't have any proposal along these lines - so the above is just noisy thoughts with no value..]

Again, that would be overkill. If the whole point of this change is to dynamically build a type name from pieces, I would just maintain XXXType being 'const char*', and handle in a non-const char buffer the building of type names. Just my 2 cents. -- Lisandro Dalc�n --------------- Centro Internacional de M�todos Computacionales en Ingenier�a (CIMEC) Instituto de Desarrollo Tecnol�gico para la Industria Qu�mica (INTEC) Consejo Nacional de Investigaciones Cient�ficas y T�cnicas (CONICET) PTLC - G�emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594