warnings in methods with enabled lexical-binding

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

_______________________________________________
cedet-eieio mailing list
cedet-eieio <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-eieio

defining methods based on built-in ELisp types

I recently started to use EIEIO in my ELisp programming.  Coming from
CLOS, I naturally started to define methods like

  (defmethod foo ((x string) ...))

  (defmethod foo ((x cons)) ...)

But this seems to be unsupported.  It looks like this lack of
functionality is behind item #2 on the EIEIO wish list ("Method
dispatch for built-in types").  Has there been any progress on this
front?

--

-- 
Jesse Alama

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Major mode for EIEIO custom buffers

Hi,

I think it would be an improvement if eieio-custom.el had its own major 
mode for the buffers it creates.

I need this because I have a minor mode that defines new key bindings for 
RET and TAB, which shadow the ones in widget-keymap. This is easily 
remedied, but it requires a hook for the buffers that eieio-custom creates. 
Rather than just adding a hook, it seems more sensible to create a simple 
major mode, as this would also improve documentation.

I've included a simple patch below.

Regards,

Leo

-----------------------------------------------------------------

diff -ruN old/eieio-custom.el new/eieio-custom.el
--- old/eieio-custom.el	2012-06-06 14:55:00.258634000 +0100
+++ new/eieio-custom.el	2012-06-06 15:05:15.311976000 +0100
 <at>  <at>  -332,6 +332,16  <at>  <at> 
 Optional argument GROUP is the sub-group of slots to display."
   (eieio-customize-object obj group))

+(defvar eieio-custom-mode-map
+  (let ((map (make-sparse-keymap)))
+    (set-keymap-parent map widget-keymap)
+    map)
+  "Keymap for EIEIO Custom mode")
+
+(define-derived-mode eieio-custom-mode fundamental-mode "EIEIO Custom"
+  "Major mode for customizing EIEIO objects.
+\\{eieio-custom-mode-map}")
+
 (defmethod eieio-customize-object ((obj eieio-default-superclass)
 				   &optional group)
   "Customize OBJ in a specialized custom buffer.
 <at>  <at>  -347,6 +357,7  <at>  <at> 
 			       (symbol-name g) "*")))
     (setq buffer-read-only nil)
     (kill-all-local-variables)
+    (eieio-custom-mode)
     (erase-buffer)
     (let ((all (overlay-lists)))
       ;; Delete all the overlays.
 <at>  <at>  -363,7 +374,6  <at>  <at> 
     (widget-insert "\n")
     (eieio-custom-object-apply-reset obj)
     ;; Now initialize the buffer
-    (use-local-map widget-keymap)
     (widget-setup)
     ;;(widget-minor-mode)
     (goto-char (point-min))

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

defclass :initform behavior

EIEIO's DEFCLASS doesn't seem to handle :INITFORM in the same manner
as does Common Lisp CLOS. There does seem to have been some discussion
of this back in 2010 ('Constructor -- lambda expression' (From: Frank
<some.frank <at> gm...> - 2010-05-29 19:44)) on this list but the issue
doesn't seem to have been resolved.

Common Lisp specifies that the form provided to :INITFORM is evaluated
only at the time a new member of the class is generated:

CL-USER> (defvar x 0)
X
CL-USER> (setf x 0)
0
CL-USER> x
0
CL-USER> (defclass xyz ()
  ((name
    :initarg :name
    :initform (setf x (1+ x))
    :type number)))
#<STANDARD-CLASS XYZ>
CL-USER> x
0
CL-USER> 

Contrast this with EIEIO:

ELISP> (defvar x 0)
x
ELISP> (setf x 0)
0
ELISP> x
0
ELISP> (defclass xyz ()
  ((name
    :initarg :name
    :initform (setf x (1+ x))
    :type number)))
xyz
ELISP> x
1

In EIEIO, DEFCLASS seems to evaluate the form passed to :INITFORM at
time of DEFCLASS invocation. Is this the intended behavior?

The EIEIO documents indicate, "The value passed to initform is
automatically quoted." Perhaps the documentation should be clarified
to be more explicit regarding whether the behavior of EIEIO is
intended to diverge from that of CLOS at this point.

Best wishes,

Alan

GNU Emacs 23.4.1 (debian emacs 23.4+1-3)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

cedet versions and compatibility

------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/

_______________________________________________
cedet-eieio mailing list
cedet-eieio <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-eieio

call-next-method invocation order

Hi there,

I'm not sure maybe there's a problem with (call-next-method)'s 
invocation order with multiple inheritance;

Check this tree out

  +--base
       +--derived1
       |    +--derived2
       |         +--derived3
       +--derivedX
            +--derived3

And here's the code for it;
Well it's kinda a complex example but the point why I bother you guys 
with it is if I run this example on Allegro CL I get a different result;
BTW if I add  :method-invocation-order :depth-first to class derived2 I 
get the same result as on Allegro CL;

As I'm not an expert in CL I'll leave it up to you guys what to do with it;

Thanks
Frank

(require 'cl)
(require 'eieio)

(defclass base ()
  ())
(defmethod func ((this base))
  (foo this))
(defmethod foo ((this base))
  (message "base::foo"))

(defclass derivedX (base)
  ())

(defclass derived1 (base)
  ())
(defmethod foo ((this derived1))
  (message "derived1::foo"))

(defclass derived2 (derived1)
  ()
;;;  :method-invocation-order :depth-first
)
(defmethod foo ((this derived2))
  (call-next-method)
  (message "derived2::foo"))

(defclass derived3 (derived2 derivedX)
  ())

(setq td1 (make-instance 'derived2))
(func td1) ;; Results in:
          ;; derived1::foo
          ;; derived2::foo

;;XXX shouldn't the result be the same as in the former example?
;;XXX on Allegro CL the result is the same as for td1
(setq td2 (make-instance 'derived3))
(func td2) ;; Results in:
          ;; base::foo
          ;; derived2::foo

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

:method-invocation-order :depth-first

Hi,

Is the :method-invocation-order :depth-first a common lisp feature?

Just curious as I'd like to know how portable this feature is;

Thanks
Frank

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

compiling error

Hello,

I tried to byte-compile-file this

(require 'eieio)

(defclass foo ()
  ())

(defmethod bar ((this foo))
  )

and I get this error

`eieio.el:8:1:Error: Symbol's value as variable is void: filename'

How can I get it to compile my file?

Thanks
Frank

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

More default methode issues

Hi,

This looks like a glitch to me.

(require 'eieio)

(defclass foo ()
  ())

(defmethod func (this)
  (message "func default %s" this))

(defmethod func :before ((this foo))
  (message "func foo :before %s" this))

;; (defmethod func :primary ((this foo))
;;   (message "func foo :primary %s" this)
;;   123)

(defmethod func :after ((this foo))
  (message "func foo :after %s" this))

;; This one is probably OK.
(func (make-instance 'foo))

;; Must be wrong as a methode which is bound for class foo is called!
;; I assume the default methode should be called.
(func 666)

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

Parent's slot overwriting

Hi,

Please try this.  I get an error if I try to evaluate the child class.

Regards,
Frank

(require 'eieio)

(defclass foo ()
  ((field :type string)))

(defclass bar ()
  ((field :type wholenum)))

;; I get an error here.
;; Apparently there's a typecheck done for field.
;;
;; The documentation says:
;;   If the new class has a slot with the same name as the parent,
;;   the new slot overrides the parent's slot.
;;
;; Is this supposed to throw an error in this case?
(defclass child (bar foo)
  ((field :type vector)))

;; This evaluates fine.
;; (defclass child (bar foo)
;;   ((field :type wholenum)))  ;; bar's field type matches child's 
field type

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

Default methods :before and :after aren't called

Hi,

Is this correct behaviour? It looks like only the :primary default 
method gets called even if there are :before and :after ones defined?

(require 'eieio)

(defclass foo ()
  ())

(defmethod func :before (this)
  (message "default method :before: %s" this))

(defmethod func :primary (this)
  (message "default method :primary: %s" this))

(defmethod func :after (this)
  (message "default method :after: %s" this))

(defmethod func :before ((this foo))
  (message "foo's method :before: %s" this))

(defmethod func :primary ((this foo))
  (message "foo's method :primary: %s" this)
  123)

(defmethod func :after ((this foo))
  (message "foo's method :after: %s" this))

(func (make-instance 'foo))
;; I'll get this which looks correct to me.
;;
;; foo's method :before: [object foo foo]
;; foo's method :primary: [object foo foo]
;; foo's method :after: [object foo foo]
;; 123

(defclass bar ()
  ())

(func (make-instance 'bar))
;; Hmmm what about the :before and :after default methods?
;;
;; default method :primary: [object bar bar]

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo