opencog-dev team mailing list archive

[Cassio Pennachin <cassio@xxxxxxxxxxxxx>]

On timing: we'll very shortly (next week) start a port of most of the  
Petaverse codebase to OpenCog as part of a paid Novamente contract.   
Changes that break NM-derived tree compatibility should be left for  
after that port, which has a not-too-generous deadline.

Cassio

On Jun 27, 2008, at 2:37 AM, Gustavo Machado Campagnani Gama wrote:

> Irk. Pressed Ctrl-Enter by mistake, sorry.
>
> On Fri, 2008-06-27 at 02:32 -0300, Gustavo Machado C. Gama wrote:
> Hi Joel,
>
> I like your proposal in general. Just two minor caveats: 1. I have
> a feeling that we will eventually end up with a few cases where the  
> name
> will be too long and unfriendly (getHandleSetByTypeOrTargetOrName...);
> 2. it'll make porting code from other novamente-derived trees a lot
> harder.
>
> But I still think the benefits outweight the drawbacks, so...
>
> +1
>
>
> --
> Gustavo
>
> > On Thu, 2008-06-26 at 14:02 +1200, Joel Pitt wrote:
> > > Hi all,
> > >
> > > There are an awful lot of overloaded getHandleSet methods in  
> > > AtomTable
> > > that return HandleEntry pointers and in AtomSpace that return
> > > OutputIterators.
> > >
> > > Is there a reason for making them overloaded instead of making them
> > > explicit in describing what type of Handle set they return?
> > >
> > > i.e. getHandleSetByImportance(AttentionValue::sti_t,
> > > AttentionValue::sti_t upperBound = 32767)
> > > instead of
> > > getHandleSet(AttentionValue::sti_t, AttentionValue::sti_t  
> > > upperBound = 32767)
> > >
> > > getHandleSetByTargets(Type*, bool*, Arity, Type type = ATOM, bool
> > > subclass = true)
> > > instead of
> > > getHandleSet(Type*, bool*, Arity, Type type = ATOM, bool subclass  
> > > = true)
> > >
> > > For the latter example, there are several overloaded methods that  
> > > get
> > > a handle set by what atoms have certain targets, and it'd make sense
> > > to leave these overloaded. Unfortunately, this change would take a
> > > while to differentiate which of the overloaded method each call  
> > > refers
> > > to, but I think it'd be worth it to make the interface friendlier to
> > > developers.
> > >
> > > I guess whether to do this depends on more for_each iterators like
> > > Linas created should be made for each equivalent getHandleSet...
> > >
> > > Any thoughts?
> > >
> > > J
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~opencog-dev
> Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/people/+me/+editemails
> More help   : https://help.launchpad.net/ListHelp

--
Cassio Pennachin
CEO, Vetta Labs
www.vettalabs.com -- +55(31)3421-6933