From: "Shot (Piotr Szotkowski)" <shot@...>
Date: 2008-06-27T17:17:52+09:00
Subject: Re: Is it ellegant to use a global variable to store a Logger object?

--2B/JsCI69OhZNC5r
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I=C3=B1aki Baz Castillo:

> El Jueves, 26 de Junio de 2008, Shot (Piotr Szotkowski) escribi=C3=B3:

>> module MyProgram
>> =C2=A0 class Logger
>> =C2=A0 class << self
>> =C2=A0 =C2=A0 def debug =E2=80=A6
>> =C2=A0 =C2=A0 =C2=A0 =E2=80=A6
>> =C2=A0 =C2=A0 end
>> =C2=A0 end
>> =C2=A0 end
>> end

> Ok, this seems really ellegant and I've tested that I can call
> "Logger.debug..." in any submodule/subclass into the program :)

:)

> Just a question: Logger must use an instance of a class (real
> class Logger), so to store it I think the best option is using
> a @@class_variable into Logger module

No =E2=80=93 by using class << self, you=E2=80=99re operating on the Logger=
 object
(an instance of the class Class), and you can access its *instance*
variables. That=E2=80=99s the other elegant part about this solution =E2=80=
=93 you can
use anything you=E2=80=99re used to, including, for example, attr_accessors.

I use this approach like in the below code; I can use stuff like

$stderr.puts 'some debug line' if Config.debug

1.upto Config.max_pins do |pin|
  =E2=80=A6
end

or decide whether to use Enumerable#map or the forkoff
gem based on whether Config.processes is one or more. :)



shot@asterix:~/work/PhD/bzr/trunk$ cat lib/art-decomp/config.rb=20
module ArtDecomp class Config

class << self

  attr_accessor :debug, :processes, :qu_method, :qv_method, :silicone

  def init
    @debug     =3D false
    @processes =3D 1
    @qu_method =3D :graph_merger
    @qv_method =3D :graph_merger
    @silicone  =3D Set[Arch[4,2], Arch[5,1]]
  end

  def log string, run, runs, dawn
    left =3D ((Time.now - dawn)/run*(runs - run)).ceil
    $stderr << " [#{string} #{runs - run} #{left}s] " if Config.debug
  end

  def max_pins
    @silicone.map{|arch| arch.pins}.max
  end

  def max_pons
    @silicone.map{|arch| arch.pons}.max
  end

  alias reset init

end

end end

ArtDecomp::Config.init
shot@asterix:~/work/PhD/bzr/trunk$=20



-- Shot
--=20
Smalltalk itself generates its own refactoring browser, test rig, IDE,
and 3D graphics subsystems as you write your program with it. So as you
structure your program, Smalltalk uses that structure to generate the
refactoring browser needed to refactor its structure. This is why some
advanced Smalltalk Gurus know the best way to program Smalltalk is to
simply pick up the CPU and shake it.         -- Phlip, comp.programming

--2B/JsCI69OhZNC5r
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFIZKQ+i/mCfdEo8UoRAjZoAJ0b3zuewhatCubUEgNcDde8+p+rMwCglukO
urDeABVpMQBcy3y1jG5NphI=
=+c/u
-----END PGP SIGNATURE-----

--2B/JsCI69OhZNC5r--