1.) It blows up the class with mostly unnecessary code.
2.) It may refer to classes that will be included in the final .swf
3.) This is not possible for interfaces so you need to have a different approach anyway, which might confuse even more.
yours
Martin.
Hello Martin,
>>> You think of runtime validation of parameters? Thats insane concerning performance and performance is what flash lacks in.
No. No runtime.
I talk about describing test situations – no matter whether you call it unit tests or DBC or something else – to be placed at the head of a method or a class.
Both are nice places, where every Jane and Joe programmer could easily find unit tests DBC description or whatever tests someone could think of.
You no more would look around in folders to find files that might do tests onto classes and you would have to know about the places of those tests.
One place right under the class head or method head would be a very nice place everyone could find.
Regards
Bernd
Von: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] Im Auftrag von Martin Heidegger
Gesendet: Sonntag, 8. Oktober 2006 15:56
An: Open Source Flash Mailing List
Betreff: Re: [osflash] Design By Contract on ActionScript 2
You think of runtime validation of parameters? Thats insane concerning performance and performance is what flash lacks in.
yours
Martin.2006/10/8, Bernd Will < [EMAIL PROTECTED] >:
Hello Martin,
You like to put the stuff outside the classes, while I would like to see tests and validation being embedded as a kind of class documentation.
Regards
Bernd
Von: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] Im Auftrag von Martin Heidegger
Gesendet: Sonntag, 8. Oktober 2006 15:32
An: Open Source Flash Mailing List
Betreff: Re: [osflash] Design By Contract on ActionScript 2
I merly know about DBC what Wikipedia tells me.
Well, thats what mocks are supposed to do - at least they should help. Once you use a mock in a unit test you should be able to check the state before and the state afterwards. Interfaces are helpers that allow generic/plugable designs. You assume a functionality by methods and documentation. Then you check the implementation using mocks. I usually create a Abstract test and extended versions for every implementation. I usually check multiple valid and invalid inputs and check the output with a Mock. That should be a fully working test of the implementation - right?
yours
Martin.2006/10/8, Bernd Will <[EMAIL PROTECTED] >:
Hello Martin,
you mean that every class should get an interface ?
DBC is more than just a syntax check, DBC allows pre and post checking as well:
http://www.wayforward.net/pycontract/
Regards
Bernd
Von: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] Im Auftrag von Martin Heidegger
Gesendet: Sonntag, 8. Oktober 2006 15:14
An: Open Source Flash Mailing List
Betreff: Re: [osflash] Design By Contract on ActionScript 2
Well - so what? Unittests together with interfaces seem to be a strategy that matches enough - doesn't it?
yours
Martin.2006/10/8, Bernd Will < [EMAIL PROTECTED] >:
Hello Martin,
"Interface" allow syntax check during compile time.
"Tests" allow semantic validation during runtime.
Regards
Bernd
Von: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] Im Auftrag von Martin Heidegger
Gesendet: Sonntag, 8. Oktober 2006 14:23
An: Open Source Flash Mailing ListBetreff: Re: [osflash] Design By Contract on ActionScript 2
To me working with interfaces is DBC. A object has a interface that allows certain usage this usage is documented and tested with unit tests. is there a need for more?
greetings
Martin.2006/10/7, Bernd Will <[EMAIL PROTECTED] >:
Hello everybody,
similar to doctest, DBC in Python is also easily injected by inserting inside those comment tags at the beginning of a method.
It is very nice seeing UNITTEST and DBC in one comment placed directly below the method's head.
Here an example for UNITTEST and DBC in Python:
def sort(a):"""Sort a list *IN PLACE*.>>> a = [1, 1, 1, 1, 1, 2, 2, 1]>>> sort(a)>>> a[1, 1, 1, 1, 1, 1, 2, 2]>>> a = 'the quick brown fox jumped over the lazy dog'.split()>>> sort(a)>>> a['brown', 'dog', 'fox', 'jumped', 'lazy', 'over', 'quick', 'the', 'the']pre:# must be a listisinstance(a, list)# all elements must be comparable with all other itemsforall(range(len(a)),lambda i: forall(range(len(a)),lambda j: (a[i] < a[j]) ^ (a[i] >= a[j])))post[a]:# length of array is unchangedlen(a) == len(__old__.a)# all elements given are still in the arrayforall(__old__.a, lambda e: __old__.a.count(e) == a.count(e))# the array is sortedforall([a[i] >= a[i-1] for i in range(1, len(a))])"""a.sort()# enable contract checkingimport contractcontract.checkmod(__name__)def _test():import doctest, sortreturn doctest.testmod (sort)if __name__ == "__main__":_test()
Regards
Bernd
Von: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] Im Auftrag von Miguel Serrano Milano
Gesendet: Samstag, 7. Oktober 2006 16:09
An: [email protected]
Betreff: Re: [osflash] Design By Contract on ActionScript 2
Hi! I've been thinking about this last days. There's no solution at the moment, but it is not difficult to develop a solution by one of this two ways:
1. Explicit asserts and an AOP approach to check and invariants. The asserts are easy to define: just a collection of Assert.precondition() and Assert.precondition(), and as invariants a method classInvariants() could be defined to be invoked after every method call.
2. A precompiler. I think there are tools to write precompilers for any language. Do somebody know something about this?
What do you think?
Message: 1
Date: Thu, 5 Oct 2006 15:11:13 -0300
From: "Marcelo de Moraes Serpa" < [EMAIL PROTECTED]>
Subject: [osflash] Design By Contract on ActionScript 2
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Is there any tool for AS2 that allows me to implement the DBC methodology?
Cheers,
Marceo.
Miguel Serrano Milano
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
ICQ: 117662935
Skype: mastakaneda
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
ICQ: 117662935
Skype: mastakaneda
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
ICQ: 117662935
Skype: mastakaneda
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
ICQ: 117662935
Skype: mastakaneda
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
ICQ: 117662935
Skype: mastakaneda
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
