Smalltalk › Pharo › Pharo Smalltalk Developers

A better way to serialise methods?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Aliaksei Syrel

A better way to serialise methods?

Hi,

Smalltalk is famous for tiny methods with just a few parameters. However, sometimes libraries written in C have methods that accept many arguments. In my case I have a method that requires to pass exactly 15 arguments, luckily 15 is maximum possible amount of arguments in Pharo, so my day was saved. Until I tried to load the same code in Window. Here is my ffi call method:

primMeasure: aTextRun start: aStart length: aMaxLength breakBefore: aLineBreakBefore width: aWidth provider: aProvider suppress: aSuppressBreak whitespace: aTrimWhitespace metrics: aMetrics boxType: aBoundingBoxType canvas: aCanvas hyphen: aUsedHyphenation lastBreak: aLastBreak wordWrap: aCanWordWrap breakPriority: aBreakPriorityPointer

^ self ffiCall: #(uint32 text_run_break_and_measure (

TextRun aTextRun,

uint32 aStart,

uint32 aMaxLength,

bool aLineBreakBefore,

double aWidth,

TextPropertyProvider aProvider,

TextSuppressBreak aSuppressBreak,

ExternalAddress aTrimWhitespace,

NativeTextMetrics aMetrics,

TextBoundingBoxType aBoundingBoxType,

Canvas aCanvas,

ExternalAddress aUsedHyphenation,

ExternalAddress aLastBreak,

bool aCanWordWrap,

ExternalAddress aBreakPriorityPointer))

If I try to commit it using filetree/gitfiletree/Iceberg I get an .st method source file with the following name (138 characters):

primMeasure.start.length.breakBefore.width.provider.suppress.whitespace.metrics.boxType.canvas.hyphen.lastBreak.wordWrap.breakPriority..st

And of course trying to clone the repo using git fails on Window because filename is too long.

So here comes the question: Is it really necessary to name method source file according to the method's #sender? Would it make sense to trim the filename and append a short hash to avoid collisions?

Cheers,

Alex

Eliot Miranda-2

Re: A better way to serialise methods?

Hi Alex,

On Jun 28, 2017, at 10:38 AM, Aliaksei Syrel <[hidden email]> wrote:

Hi,

Smalltalk is famous for tiny methods with just a few parameters. However, sometimes libraries written in C have methods that accept many arguments. In my case I have a method that requires to pass exactly 15 arguments, luckily 15 is maximum possible amount of arguments in Pharo, so my day was saved. Until I tried to load the same code in Window. Here is my ffi call method:

primMeasure: aTextRun start: aStart length: aMaxLength breakBefore: aLineBreakBefore width: aWidth provider: aProvider suppress: aSuppressBreak whitespace: aTrimWhitespace metrics: aMetrics boxType: aBoundingBoxType canvas: aCanvas hyphen: aUsedHyphenation lastBreak: aLastBreak wordWrap: aCanWordWrap breakPriority: aBreakPriorityPointer

^ self ffiCall: #(uint32 text_run_break_and_measure (
TextRun aTextRun,
uint32 aStart,
uint32 aMaxLength,
bool aLineBreakBefore,
double aWidth,
TextPropertyProvider aProvider,
TextSuppressBreak aSuppressBreak,
ExternalAddress aTrimWhitespace,
NativeTextMetrics aMetrics,
TextBoundingBoxType aBoundingBoxType,
Canvas aCanvas,
ExternalAddress aUsedHyphenation,
ExternalAddress aLastBreak,
bool aCanWordWrap,
ExternalAddress aBreakPriorityPointer))

If I try to commit it using filetree/gitfiletree/Iceberg I get an .st method source file with the following name (138 characters):
primMeasure.start.length.breakBefore.width.provider.suppress.whitespace.metrics.boxType.canvas.hyphen.lastBreak.wordWrap.breakPriority..st

And of course trying to clone the repo using git fails on Window because filename is too long.
So here comes the question: Is it really necessary to name method source file according to the method's #sender? Would it make sense to trim the filename and append a short hash to avoid collisions?

IMO file per class with methods ordered by selector makes even more sense. Provided methods are ordered by selector then incidental changes such as protocol or version stamp won't cause false differences to be shown.

Cheers,
Alex