1 |
summary: unhandled keywords to goops "make" (etc) should signal errors |
summary: unhandled keywords to goops "make" (etc) should signal errors |
2 |
reported: "Neil W. Van Dyke" <nwv@neilvandyke.org>, 2002-03-09 |
reported: "Neil W. Van Dyke" <nwv@neilvandyke.org>, 2002-03-09 |
3 |
|
|
4 |
Currently (latest Guile 1.5.4 from CVS), keyword arguments to the Goops |
Neil W. Van Dyke sez: |
|
"make" method that are not handled do not generate errors. |
|
5 |
|
|
6 |
Unless I misunderstand the way that Goops is to be used, I think that |
> Currently (latest Guile 1.5.4 from CVS), keyword arguments to the Goops |
7 |
the default behavior should be to consider unhandled keyword arguments |
> "make" method that are not handled do not generate errors. |
8 |
invalid. |
> |
9 |
|
> Unless I misunderstand the way that Goops is to be used, I think that |
10 |
Considering unhandled keyword arguments invalid would catch some serious |
> the default behavior should be to consider unhandled keyword arguments |
11 |
programming errors, such as mistyped initializer keywords, and |
> invalid. |
12 |
accidental neglect to define an initializer keyword for a slot. |
> |
13 |
|
> Considering unhandled keyword arguments invalid would catch some serious |
14 |
The example below illustrates an unhandled keyword being ignored. |
> programming errors, such as mistyped initializer keywords, and |
15 |
|
> accidental neglect to define an initializer keyword for a slot. |
16 |
(use-modules (oop goops) |
> |
17 |
(oop goops describe)) |
> The example below illustrates an unhandled keyword being ignored. |
18 |
|
> |
19 |
(define-class <my-class> () |
> (use-modules (oop goops) |
20 |
(xxx #:init-value #f #:init-keyword #:foo) |
> (oop goops describe)) |
21 |
(yyy #:init-value #f #:init-keyword #:bar)) |
> |
22 |
|
> (define-class <my-class> () |
23 |
(define obj (make <my-class> #:foo 42 #:xxxyyyzzz 69 #:bar 24)) |
> (xxx #:init-value #f #:init-keyword #:foo) |
24 |
;; ^^^^^^^^^^^ |
> (yyy #:init-value #f #:init-keyword #:bar)) |
25 |
;; Unhandled keyword |
> |
26 |
|
> (define obj (make <my-class> #:foo 42 #:xxxyyyzzz 69 #:bar 24)) |
27 |
(describe obj) |
> ;; ^^^^^^^^^^^ |
28 |
|
> ;; Unhandled keyword |
29 |
When run, the above produces output something like the following, which |
> |
30 |
shows that both xxx and yyy were set and that no error was generated. |
> (describe obj) |
31 |
|
> |
32 |
#<<my-class> 8086bc0> is an instance of class <my-class> |
> When run, the above produces output something like the following, which |
33 |
Slots are: |
> shows that both xxx and yyy were set and that no error was generated. |
34 |
xxx = 42 |
> |
35 |
yyy = 24 |
> #<<my-class> 8086bc0> is an instance of class <my-class> |
36 |
|
> Slots are: |
37 |
Thank you for considering this suggestion. |
> xxx = 42 |
38 |
|
> yyy = 24 |
39 |
|
> |
40 |
|
> Thank you for considering this suggestion. |
41 |
|
|
42 |
|
2002-04-25 ttn sez: |
43 |
|
|
44 |
|
> because my personal coding has not yet advanced to using goops |
45 |
|
> regularly, my conjecture from reading related material is that keyword |
46 |
|
> handling in goops follows a non-blocking scheme reflecting its original |
47 |
|
> design model. i imagine when i do finally get to designing classes and |
48 |
|
> instantiating objects, i would view mixin techniques darkly if they were |
49 |
|
> (in return) so opaque. |
50 |
|
|
51 |
|
(this just means an object system that allows easy (low-stress) passing of |
52 |
|
specialization args around is good for implementing orthogonal features.) |
53 |
|
|
54 |
|
the real question is: what are the mechanisms required to implement such |
55 |
|
"error" checking as an orthogonal feature to guile? if these mechanisms are |
56 |
|
available to the user, this bug can be closed. |