Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Correlations among VFP and OOP languages
Message
De
12/06/2006 04:08:37
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Programmation Orientée Object
Divers
Thread ID:
01128092
Message ID:
01128398
Vues:
21
Hi David,
>That would do it, but at the cost of explicitly requiring no dodefault() call in the the subclass. This is dangerous because it's only true at the first level of subclass . And since you may not know when code at a higher level will be inserted. For example:

My example was just typed in, as my missing out returning the method name of the abstract shows <g>.
Your objection is certainly valid, but something along the lines of
function AbstractWarn()
  local lcSetAssert, lcAbsCaller
  lcAbsCaller = Program(program(-1)-1)
  if not JustExt(m.lcAbsCaller)==JustExt(Program(program(-1)-2))
    lcSetAssert = set("Assert")
    set Assert on
    assert .f. Message m.lcAbsCaller + " should be overwritten !"
    set Assert &lcSetAssert
  endif
should be able to fix it for most usages (Again just typed in not tested ...Update - and on second reading might need some error checking to make sure there *is* a programmatic level -2 /Update). The case of a method *just* calling the dodefault() could be argued to be something for the code police or a valid use case suppressing the assert<g>. For me having explicit abstract levels has no merit *in vfp* unless there is some automatic tool working on extracting documentation on such levels or other on site "programming rules". But now we are deep in "opinion space".

regards

thomas
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform