change to petsc-dev

[Lisandro Dalcin]

On 6/24/08, Satish Balay <balay at mcs.anl.gov> 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