Sunday, February 3, 2008

Copycat's codelets, refactored (i)

From Analogy-Making as Perception (By Melanie Mitchell), MIT Press.

Here is Melanie's classification of codelets:

DESCRIPTION BUILDING CODELETS

  1. Bottom-up description scout.
  2. Top-down description scout.
  3. Description strength tester.
  4. Description builder.

BOND BUILDING CODELETS

  1. Bottom-up bond scout
  2. Top-down bond scout (deals with categories, such as successor)
  3. Top-down bond scout (deals with direction of strings)
  4. Bond-strenght tester
  5. Bond Builder

GROUP BUILDING CODELETS

  1. Top-down group scout (for categories)
  2. Top-down group scout (for direction)
  3. Group-string scout
  4. Group strength tester
  5. Group builder

CORRESPONDENCE BUILDING CODELETS

  1. Bottom-up correspondence scout
  2. Important-object correspondence scout
  3. Correspondence strength tester
  4. Correspondence builder

RULE BUILDING CODELETS

  1. Rule scout
  2. Rule Strength tester
  3. Rule Builder
  4. Rule Translator

OTHER CODELETS

  1. Replacement finder
  2. Breaker

24 codelets in all. Interesting. Not so many.

I wonder how we could use polymorphism to reduce duplicate code and enable the separation of essence from accident.

For example, take the codelet groups:

DESCRIPTION BUILDING CODELETS
BOND BUILDING CODELETS
GROUP BUILDING CODELETS
CORRESPONDENCE BUILDING CODELETS
RULE BUILDING CODELETS

Each of these groups have a number of different codelets. But look again, and a clear pattern emerges: Each of the groups has scouts, has testers, and has builders. (Also, scouts are either bottom-up or top-down.) I can't convince myself that there isn't another, better, way to design this than by programming each one individually.

We have to separate FARG essence from copycat's letter-string's accidental features. And, in the way towards that road, we will stumble upon general codelets: the holy grail. Codelets that are general enough to work on any domain; codelets that follow the principle of closed for modification, and open for extension. If we can finish this design in this first semester, that will be a powerful moment.

4 comments:

Rejane said...

As far as I've analyzed inheritance has to be implemented and as a consequence polymorphism is applied in the methods.

If you would like more informations and explanations about it, please email me.

Regards,
Rejane

Rejane said...

As far as I've analyzed inheritance has to be implemented and as a consequence polymorphism is applied in the methods.

If you would like more information and explanation about it, please email me.

Regards,
Rejane.

Rejane said...

As far as I've analyzed inheritance has to be implemented and as a consequence polymorphism is applied in the methods.

If you would like more information and explanation about it, please email me.

Regards,
Rejane.

Rejane said...

O conceito de Hernaça e Polimorfismo andam juntos. Vou te dar um exemplo, e vai ficar mais fácil sua compreensão:

Imagine uma classe que tenha uma Conta Bancária Simples, chamada ContaSimples e que tenha os métodos depositar(), donodaconta(), versaldo(), retirar().
Agora vamos usar uma herança, e uma classe poupança vai herdar todos os métodos da classe Conta Simples acima, e vamos ainda adicionar um método Juros() na classe Poupança.

Acabamos de usar herança.

Polimorfismo, significa 'muitas formas'
Agora vc pode usar o polifmorfismo, ou seja, vc vai poder usar o depositar(), tanto para a Classe Simples, quanto a para Poupança, resumindo, vc usou de 2 formas diferentes o mesmo método.

Desculpa o atraso....