What's so special about operators, built-in classes and modules?

[Jim Freeze]

I just noticed this little quirk. Is there something
I am doing wrong?

module Mod
def *(other)
puts "#{self} * #{other}"
end
end

class String
include Mod
end

"ff" * 5 #=> nothing

But, if I add the method explicitly instead of through a module I get:

class String
#include Mod
def *(other)
puts "#{self} * #{other}"
end
end

"ff" * 5 #=> "ff" * 5

This seems to be a quirk (bug?) and only happens when mixing modules,
built in classes (like Array) and operator methods.

Mixing in a module works fine with the combinations:
Non built-in class, operators
Built-in class, non operator method

 

[Florian Frank]

On 2005-07-26 07:43:29 +0900, Jim Freeze wrote:
[...]

module Mod
def f; :f;end
end

class A;
end
class A;
include Mod
end
A.new.f # => :f

class B
def f; :g;end
end
class B
include Mod
end
B.new.f # => :g

class B
def f; :f;end
end
B.new.f # => :f

String.method_defined?*) # => true

 

[Jim Freeze]

class B
def f; :g;end
end
class B
include Mod
end
B.new.f # => :g

Thanks Forian. For some reason I always thought that including a mod
would shadow old methods.
I suppose for my method to work (no pun intended), the standard
operating procedure is to:

class B
alias :_orig_f
remove_method :f
include Mod
end

I'm a little slow in getting around to these types of things, I'm
surprised I haven't seen an RCR to reduce this to a single line.

 

[Florian Frank]

I'm a little slow in getting around to these types of things, I'm
surprised I haven't seen an RCR to reduce this to a single line.

You can use Ruby to do most of the work:

module Mod
def f; :"new-f"; end
def self.included(o)
instance_methods(false).each do |m|
o.instance_eval do
alias_method("_orig_#{m}", m)
remove_method(m)
end
end
super
end
end

class A
def f; :f; end
end

A.new.f # => :f

class A
include Mod
end

A.new._orig_f # => :f
A.new.f # => :"new-f"

 

[Joel VanderWerf]

Thanks Forian. For some reason I always thought that including a mod
would shadow old methods.
I suppose for my method to work (no pun intended), the standard
operating procedure is to:

class B
alias :_orig_f
remove_method :f
include Mod
end

I'm a little slow in getting around to these types of things, I'm
surprised I haven't seen an RCR to reduce this to a single line.

Including a module is just like inheriting from a class--the module is
above you in the ancestor list. I guess the intuitive meaning of
"include" might be different--one might think it meant "define all
methods from the module at this point in my class definition". Maybe
"inherit <module>" would be a better name for the construct...

So would the RCR be for a construct that inserted a module between each
instance of B and B itself?

 

[Jim Freeze]

Including a module is just like inheriting from a class--the module is
above you in the ancestor list. I guess the intuitive meaning of
"include" might be different--one might think it meant "define all
methods from the module at this point in my class definition". Maybe
"inherit <module>" would be a better name for the construct...

My simple thought process was always thinking that 'include'ing a Module
was the same as writing the methods myself. So

class A
def m
puts "A#m"
end
def m
puts :m
end
end
A.new.m #=> :m

was the same thing as

module Mod
def m
puts :m
end
end
class A
def m
puts "A#m"
end
include Mod
end
A.new.m #=> :m

So, I thought it was redefining the method and the old method
was being lost if it did not have an alias.

But, as you say, it is more like inheritance.

So would the RCR be for a construct that inserted a module between each
instance of B and B itself?

Would be nice if the notation was external to the class
since there is no difference between:

class A
include Mod
def m; puts "A#m"; end
end

and

class A
def m; puts "A#m"; end
include Mod
end

 

[Daniel Brockman]

One week and five days ago,

I thought that the methods and constants in a module were
just inserted into a class.

Yet another reason why modules and classes should
be unified.

I don't see it, personally. I really don't see why they
should be unified in the least.

Twelve hours ago,

For some reason I always thought that including a mod
would shadow old methods.

Dear Austin,

While the superficial and cosmetic difference between these
two almost completely equivalent concepts continue to
mislead users, do you still not see =E2=80=9Cin the least=E2=80=9D any
reason whatsoever to unify them?

Oh, and before someone comes shouting =E2=80=9Cbut classes can be
instantiated and modules can't,=E2=80=9D let me just post this:

class Module
def new(*a, &b)
const_defined?Viagra) or
const_setViagra, Class.new.include(self))
const_getViagra).new(*a, &b)
end
end

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Austin Ziegler]

=20

=20

=20
Twelve hours ago,

=20
Dear Austin,
=20
While the superficial and cosmetic difference between these
two almost completely equivalent concepts continue to
mislead users, do you still not see "in the least" any
reason whatsoever to unify them?

Nope. I'll note that others have argued better in favour of this than
you have and they're still not unified. I think that unification would
increase the confusion far MORE than what is currently present.

Oh, and before someone comes shouting "but classes can be
instantiated and modules can't," let me just post this:
=20
class Module
def new(*a, &b)
const_defined?Viagra) or
const_setViagra, Class.new.include(self))
const_getViagra).new(*a, &b)
end
end

That's not instantiating a module. It's cute, but it's not
instantiating a module.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Daniel Brockman]

Nope.

Then I'm forced to conclude that you are shying away from
the truth, as it is staring you in the face.

I'll note that others have argued better in favour
of this than you have and they're still not unified.

That's a new one =E2=80=94 argument by pointing out that there are
better arguments in favor of the opposing side.

I think that unification would increase the confusion far
MORE than what is currently present.

That is a reasonable belief. Indeed, I'm not completely
sure myself that unification would reduce net confusion.
So I'd be interested in seeing some arguments.

Here is an example of an argument:

Whenever you bring up the issue of modules vs. classes,
there will generally be at least one person who believes
that including a module is the same as copying its body.
This confusion would go away if the two were unified.

That's not instantiating a module. It's cute, but it's not
instantiating a module.

Of course it's not instantiating a module, but it's pretty
much _as good as_ instantiating a module. It lets you use
modules instead of classes, which demonstrates that the
distinction is superficial.

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Ara.T.Howard]

That is a reasonable belief. Indeed, I'm not completely sure myself that
unification would reduce net confusion. So I'd be interested in seeing some
arguments.

well - classes can't do this

module MainHelper
...
end

module SetupMain
include MainHelper
def run
...
end
end

module QueryMain
include MainHelper
def run
...
end
end

module BackupMain
include MainHelper
def run
...
end
end

class Main
def main
table = {
SETUP => SetupMain,
QUERY => QueryMain,
BACKUP => BackupMain,
}
modul = table[ mode ]
extend modul
run
end
end

this sort of aggregation can be very nice for source management when classes
are growing large - one can simply make the class be what it needs to be and
nothing more. in short - classes do not support ad hoc aggreation, which is
very nice feature to give up.

Here is an example of an argument:

Whenever you bring up the issue of modules vs. classes,
there will generally be at least one person who believes
that including a module is the same as copying its body.
This confusion would go away if the two were unified.

this is a similar 'argument':

in c most people think that a definition like

int foobar (const char * string);

will prevent people from modifiying string. it won't. for that one needs

int foobar (const char * const string);

why not unify them?

the answer is obvious: because they are differnet. a focus on clarifying
doccumentation might be wiser in this case. and, in the end, certain people
are simply going to have to be told to rtfm - not everything can be intuitive
AND powerful.

Of course it's not instantiating a module, but it's pretty
much _as good as_ instantiating a module. It lets you use
modules instead of classes, which demonstrates that the
distinction is superficial.

does it?

harp:~ > cat a.rb
class Module
def new(*a, &b)
(@__klass__ ||= (m = self and Class::new{ include m }))::new(*a, &b)
end
end

module M
class << self
def class_method
42
end
end
def instance_method
42
end
end

m = M::new
p m.instance_method
p m.class.class_method

harp:~ > ruby a.rb
42
a.rb:21: undefined method `class_method' for #<Class:0xb75d0480> (NoMethodError)

and, of course, you still can't inherit from M - but i realize this needed be
so.

i think i'm with austin on this one.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================

 

[Daniel Brockman]

That is a reasonable belief. Indeed, I'm not completely
sure myself that unification would reduce net confusion.
So I'd be interested in seeing some arguments.

well - classes can't [extend objects] [...]

Is that an argument in favor of unifying them?

this is a similar 'argument':

in c most people think that a definition like

int foobar (const char * string);

will prevent people from modifiying string. it won't.
for that one needs

int foobar (const char * const string);

why not unify them?

the answer is obvious: because they are differnet.

I agree. My point is that Ruby's classes and modules are
very much alike. If =E2=80=98const char *=E2=80=99 and =E2=80=98const ch=
ar * const=E2=80=99
were very much alike, I'd be in favor of unifying them.
But since the two pointer types are not alike at all, your
analogy doesn't apply.

I'm talking about two very similar concepts that are
commonly mistaken for very different concepts, while you are
talking about two very different concepts that are commonly
mistaken for equal concepts. Do you see the difference?

a focus on clarifying doccumentation might be wiser in
this case.

Documentation in always nice, but I'm afraid the quality of
the documentation is irrelevant to the discussion at hand.

and, in the end, certain people are simply going to have
to be told to rtfm
Granted.

not everything can be intuitive AND powerful.

But realize that what I'm saying is that Ruby is *not* more
powerful with classes and modules separate than it would be
with them unified. I'm saying that Ruby would be equally
powerful (nay, more powerful) after the unification.

Would it be more intuitive? I think so.

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Daniel Brockman]

Hmm, for some reason this part of your message was left out
of my reply buffer, so I forgot to reply to it!

Of course it's not instantiating a module, but it's
pretty much _as good as_ instantiating a module. It lets
you use modules instead of classes, which demonstrates
that the distinction is superficial.

does it?

[Complicated way of saying module.new.class !=3D module.]

As I trust you are already aware, that's easily fixed:
Just redefine the =E2=80=98class=E2=80=99 method to return the module.

and, of course, you still can't inherit from M - but i
realize this needed be so.

Yes, you can:

module N
include M
end

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Ara.T.Howard]

--8323328-1989049411-1122484267=:4734
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1989049411-1122484267=:4734"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-1989049411-1122484267=:4734
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hmm, for some reason this part of your message was left out
of my reply buffer, so I forgot to reply to it!

That's not instantiating a module. It's cute, but it's
not instantiating a module.

Of course it's not instantiating a module, but it's
pretty much _as good as_ instantiating a module. It lets
you use modules instead of classes, which demonstrates
that the distinction is superficial.

does it?

[Complicated way of saying module.new.class !=3D module.]

As I trust you are already aware, that's easily fixed:
Just redefine the =E2=80=98class=E2=80=99 method to return the module.

yes - just pointing out there's more to being a class than having a new
method...

Yes, you can:

module N
include M
end

the problem is a bit deeper than that and stem from the fact that including=
a
module does not inject the included modules singleton methods into the
'includee'. for example (note this has the fix suggested above):

harp:~ > cat a.rb
class Module
def new(*a, &b)
(@__klass__ ||=3D (m =3D self and Class::new{ include(@@m =3D m); de=
f class;@@m;end }))::new(*a, &b)
end
end
module M
class << self
def class_method
42
end
end
def instance_method
42
end
end

module N
include M
end

begin
m =3D M::new
p m.class
p m.instance_method
p m.class.class_method
rescue =3D> e
puts "#{ e.message } (#{ e.class }"
end

begin
n =3D N::new
p n.class
p n.instance_method
p n.class.class_method
rescue =3D> e
puts "#{ e.message } (#{ e.class }"
end

harp:~ > ruby a.rb
M
42
42
N
42
undefined method `class_method' for N:Module (NoMethodError

i'm not saying it's not possible - just that it's a bit more work than you'=
re
suggesting. doing things consistently at an object, class, module, and
singleton_class level gets very confusing very quicky - just check out the =
code
for my traits lib to see just how. ;-)

i personally often get around this detail by

module M
module ClassMethods
end
module InstanceMethods
end
include InstanceMethods
self.extend ClassMethods
def self::included other
class << other
include InstanceMethods
end
other.extend ClassMethods
end
end

or something similar - in otherwords factor out class methods so that can b=
e
added individually to other classes/modules when they are included there.
thus begins the trickiness...


(ps. for some reason the charset from your message is very odd - it may be =
on
my end but thought you might like to know. it looks like some sort of esca=
pe
chars around '@' signs - coloring?)

cheers.

-a
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

--8323328-1989049411-1122484267=:4734--
--8323328-1989049411-1122484267=:4734--

 

[Ara.T.Howard]

That is a reasonable belief. Indeed, I'm not completely
sure myself that unification would reduce net confusion.
So I'd be interested in seeing some arguments.

well - classes can't [extend objects] [...]

Is that an argument in favor of unifying them?

i don't think so. the reason is that if classes could extend objects we'd
have a real issue with ancestors/inheritence. what i mean is that if one
could

class A
end
class B
include A
end

and this were the 'same' as

class B < A
end

then that __would__ be confusing since including multiple classes would imply
multiple inheritence. if it did not imply multiple inheritence would the only
difference be that one (B < A) made b.is_a?(A) true while the other (B.include
A) did not - even though, for all intents and purposes they could do all the
same things. this seems broken and confusing either way - tough i'll admit
the idea is interesting...

I agree. My point is that Ruby's classes and modules are
very much alike.

execept - and this is important - wrt inheritence.

were very much alike, I'd be in favor of unifying them.
But since the two pointer types are not alike at all, your
analogy doesn't apply.

and i'm saying they are not that much alike because on this crucial
difference.

Documentation in always nice, but I'm afraid the quality of
the documentation is irrelevant to the discussion at hand.

requiring people to understand the language fully, regardless of what that
takes, before attempting to change it is never really irrelevant is it?

But realize that what I'm saying is that Ruby is *not* more
powerful with classes and modules separate than it would be
with them unified. I'm saying that Ruby would be equally
powerful (nay, more powerful) after the unification.

well - if you can work out how inheritence would work out - then maybe.
realize that i'm one of those people that think that normal hackers cannot
handle multiple inheritence anyhow and that, at the very least, it's an idea
far less powerfull than mixins.

cheers.


-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================

 

[Daniel Brockman]

the problem is a bit deeper than that and stem from the
fact that including a module does not inject the included
modules singleton methods into the 'includee'.

Right, but to me that is just another reason to unify.
How is this inconsistency a feature? Why is it not fixed?

Does any code depend on the fact that including a module
does not pull in its singleton methods?

(This deserves a thread of its own, and in fact probably
already has at least one. I'll search the archives later.)

[snipped nice example code]

i'm not saying it's not possible - just that it's a bit
more work than you're suggesting. doing things
consistently at an object, class, module, and
singleton_class level gets very confusing very quicky -
just check out the code for my traits lib to see just how.
;-)

i personally often get around this detail by

module M
module ClassMethods
end
module InstanceMethods
end
include InstanceMethods
self.extend ClassMethods
def self::included other
class << other
include InstanceMethods
end
other.extend ClassMethods
end
end

or something similar - in otherwords factor out class
methods so that can be added individually to other
classes/modules when they are included there. thus begins
the trickiness...

Yes, I use similar hacks too. But don't you agree that it
would be nicer if modules and classes were consistent in
this regard, rendering these hacks unnecessary?

(I realize that I'm shifting the discussion instead of
meeting your arguments.)

(ps. for some reason the charset from your message is very
odd - it may be on my end but thought you might like to
know. it looks like some sort of escape chars around '@'
signs - coloring?)

Hmm... sounds weird. I do tend to use Unicode characters,
specifically quotation marks. How does this look?

=E2=80=98foo=E2=80=99 =E2=80=9Cbar=E2=80=9D

It's supposed to be the word foo in single quotes followed
by the word bar in double quotes.

--=20
Daniel Brockman <[email protected]>

So really, we all have to ask ourselves:
Am I waiting for RMS to do this? --TTN.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: What's so special about operators, built-in classes and modules?"

|> well - classes can't [extend objects] [...]
|
|Is that an argument in favor of unifying them?

Then you will have complex network of classes instead of simple tree
structure, sharing code with modules. That makes things much complex,
without buying you anything except for the feeling of being more generic.

matz.

 

[Daniel Brockman]

That is a reasonable belief. Indeed, I'm not completely
sure myself that unification would reduce net confusion.
So I'd be interested in seeing some arguments.

well - classes can't [extend objects] [...]

Is that an argument in favor of unifying them?

i don't think so. the reason is that if classes could
extend objects we'd have a real issue with
ancestors/inheritence. what i mean is that if one could

class A
end
class B
include A
end

and this were the 'same' as

class B < A
end

then that __would__ be confusing since including multiple
classes would imply multiple inheritence.

And how is that confusing? It's exactly what currently
happens when you include multiple modules.

module A ; end
module B ; end

class C
include A
include B
end

C.new.is_a? A #=> true
C.new.is_a? B #=> true

if it did not imply multiple inheritence would the only
difference be that one (B < A) made b.is_a?(A) true while
the other (B.include A) did not -

I don't see how this could ever make sense.

even though, for all intents and purposes they could do
all the same things. this seems broken and confusing
either way - tough i'll admit the idea is interesting...

The version that doesn't have B.include(A) imply b.is_a?(A)
does seem broken and confusing, but is a straw man.

execept - and this is important - wrt inheritence.

How so?

and i'm saying they are not that much alike because on
this crucial difference.

See above.

requiring people to understand the language fully,
regardless of what that takes, before attempting to change
it is never really irrelevant is it?

If anything I said in this thread was out of ignorance, I
apologize for my arrogance. However, I would appreciate it
if you would point any such errors out.

well - if you can work out how inheritence would work out
- then maybe.

But inheritance would work exactly the same as it does now.

realize that i'm one of those people that think that
normal hackers cannot handle multiple inheritence anyhow
and that, at the very least, it's an idea far less
powerfull than mixins.

How is multiple inheritance far less powerful than mixins?

(I actually consider Ruby's mixins to *be* a kind of
multiple inheritance, but I'll play along for a while.)

 

[Joel VanderWerf]

Very nice technique, but...

module M
module ClassMethods
end
module InstanceMethods
end
include InstanceMethods
self.extend ClassMethods
def self::included other
class << other
include InstanceMethods

^^^^^^^^^^^^^^^^^^^^^^^
This is redundant.

end
other.extend ClassMethods
end
end

For the newbies: In the old, old days (1.6 maybe), we had to use
#append_features instead of #included, and that did require explicitly
including the module. And sometimes we had to whack it with a dinosaur
bone to make it work.

Btw, the doc for append_features is unclear (as someone else on this
thread pointed out) about the difference between including a module and
adding methods:

------------------------------------------------- Module#append_features
append_features(mod) => mod
------------------------------------------------------------------------
When this module is included in another, Ruby calls
+append_features+ in this module, passing it the receiving module
in _mod_. Ruby's default implementation is to add the constants,
methods, and module variables of this module to _mod_ if this
module has not already been added to _mod_ or one of its ancestors.
See also +Module#include+.

 

[Sylvain Joyeux]

(I actually consider Ruby's mixins to *be* a kind of

multiple inheritance, but I'll play along for a while.)

Theoretically, you can't have a base class use derived class methods
because a) the base class should be instantiable b) in OO you can't force
the derived class to define a method.

Dynamic language allow (b) but it would feel strange anyway

About (a), one assumption you have is that modules should be instantiable.
Enumerable, for instance, is not even using the trick you sent earlier
because no method in the resulting object would be usable.

In the C++ world (if you know it), modules are a form of CRTP.
Regards,

 

[Ara.T.Howard]

--8323328-2109231869-1122488111=:4734
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2109231869-1122488111=:4734"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-2109231869-1122488111=:4734
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Right, but to me that is just another reason to unify.
How is this inconsistency a feature? Why is it not fixed?

Does any code depend on the fact that including a module
does not pull in its singleton methods?

i'd say __all__ code depends on that. otherwise

module M
def self::new
raise
end
end
class < C
include M
end

c =3D C::new

i'd imagine this is the (one of) reason(s) for the current behaviour.

Yes, I use similar hacks too. But don't you agree that it
would be nicer if modules and classes were consistent in
this regard, rendering these hacks unnecessary?

yes - i just am not seeing how it could be done in a way that preserved or
added to current functionality and was simpler. inheritence needs to be
addressed specifically for it to make sense.

(I realize that I'm shifting the discussion instead of
meeting your arguments.)


Hmm... sounds weird. I do tend to use Unicode characters,
specifically quotation marks. How does this look?

=E2=80=98foo=E2=80=99 =E2=80=9Cbar=E2=80=9D

like this

.[0m~@~Xfoo.[0m~0~X .[0m~@~\bar.[0m~@~]

It's supposed to be the word foo in single quotes followed
by the word bar in double quotes.

tough to see that ;-)

cheers.

-a
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

--8323328-2109231869-1122488111=:4734--
--8323328-2109231869-1122488111=:4734--